Blog

How Small Businesses Can Fortify Serverless App Security: A Practical, Actionable Guide

Hello there, fellow digital traveler! In today’s fast-paced business world, chances are you’ve either heard of “serverless” applications or you’re already using them without even realizing it. They’re a game-changer for small businesses, offering incredible flexibility, agility, and cost savings. But just like any powerful tool, they come with their own set of security considerations. You might be wondering, “How can serverless application security be strengthened?” It’s a great question, and we’re here to help you get practical, actionable answers.

I’m a security professional, and my goal today isn’t to alarm you, but to empower you with the knowledge and concrete steps you need to take control of your digital security. This isn’t just about technical jargon; it’s about understanding the real risks and how to effectively manage them, whether you’re handling things yourself or working with an IT service provider.

Before we dive into the “how-to,” let’s quickly clarify what “serverless” truly means for your business, and more importantly, your role in its security. Imagine you need to run a quick errand. With traditional servers, it’s like owning a car for that one errand, even though it sits idle most of the time. Serverless is like calling a taxi: you only pay for the ride (the time the function runs), you don’t own or maintain the car, and you don’t worry about parking it. For your business, it means you don’t manage physical servers, you pay only for what you use, and your applications automatically scale to handle traffic spikes effortlessly. It’s fantastic for dynamic websites, mobile app backends, or processing data efficiently.

This leads us to a critical distinction known as the Shared Responsibility Model. Your cloud provider (like AWS, Azure, or Google Cloud) is responsible for the security of the cloud—that’s the underlying hardware, infrastructure, and physical security. Think of them as securing the building. However, you (or your IT partner) are responsible for security in the cloud. This includes your application code, your data, and how your serverless services are configured. You’re responsible for what goes on inside your office within that building. Grasping this distinction is step one in taking control!

What You’ll Achieve in This Practical Serverless Security Guide

• The unique security risks associated with serverless applications, simplified for everyday understanding.
• Practical, actionable steps you can take (or ensure your IT team takes) to significantly enhance your serverless security posture.
• Crucial organizational practices that complement technical safeguards, helping you build a more robust defense.
• How to confidently ask the right questions and make informed decisions about your serverless app security.

Before We Begin: Getting Started with Serverless Security

You don’t need to be a coding wizard or a cloud architect to follow along, but a few things will help:

• Basic Internet Savvy: An understanding of how websites and applications generally work online.
• Awareness of Your Tools: Knowing if your business uses cloud-based services (like website hosting, mobile app backends, or data processing tools) that might be utilizing serverless technology.
• Access (or an IT Partner): Either you have some administrative access to your cloud provider’s console (e.g., AWS, Azure, Google Cloud) or, more likely, you work with an IT service provider who manages these for you. This guide will empower you to understand what to discuss with them.

Estimated Time: Approximately 60-90 minutes for initial review and planning. Many steps involve ongoing practices rather than a one-time setup. The focus is on understanding and strategic action, not complex configuration.

Step 1: Implement “Least Privilege” for Serverless Functions and Users

One of the biggest security risks in serverless applications is granting too much access. It’s like giving everyone a master key when they only need access to one room.

Understand Over-Privileged Access: When a serverless function or a user account is given more permissions than it actually needs to perform its job, it becomes a major vulnerability. If an attacker gains access to that function or account, they could potentially do far more damage than necessary. It’s similar to giving a temporary delivery driver the master key to your entire business; if they lose it, you’ve got a much bigger problem.

Small Business Scenario: Imagine your serverless function processes customer orders and only needs to read customer data and write to an order database. If it’s accidentally given permission to delete your entire customer database, a simple coding error or an attacker exploiting another vulnerability could wipe out your business. Implementing “least privilege” prevents this catastrophic outcome.

Action: Grant Minimal Necessary Permissions: This fundamental principle is called “least privilege.” For every serverless function, every user account, and every automated process, ensure it only has the bare minimum permissions required to perform its specific task—nothing more. This is a cornerstone of a Zero Trust approach.

How-to for SMB: Regularly review who and what can access your serverless components. If you have an IT service provider, insist they follow this fundamental security principle rigorously. Ask them, “Are all our serverless functions and user accounts configured with the least privilege necessary? For example, does our order processing function only have read access to customer data and write access to the orders table, and nothing else?”

Code Example (Conceptual IAM Policy for AWS):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" // ONLY allows reading objects from S3 ], "Resource": "arn:aws:s3:::your-bucket-name/*" // Specific to ONE S3 bucket }, { "Effect": "Deny", // Explicitly denies everything else to be safe "Action": "*", "Resource": "*" } ] }

Explanation: This isn’t a full serverless function, but a policy you’d attach to one. It explicitly states that this function can only read data from a specific Amazon S3 storage bucket. It’s locked down tightly, preventing it from deleting files, writing to other buckets, or accessing other cloud services it doesn’t need.

Expected Output: Your serverless functions and users operate with strictly limited access, significantly reducing the potential impact of a breach.

Pro Tip: Implement regular audits of permissions. What was “least privilege” yesterday might be over-privileged today if a function’s role changes. Don’t set it and forget it.

Step 2: Fortify Your Front Door with API Gateways for Serverless Security

Your serverless applications need a good bouncer, someone to check IDs and filter out the bad guys before they even get close.

Action: Utilize an API Gateway as a Primary Security Buffer: Think of an API Gateway as the sophisticated security guard at the entrance to your serverless functions. All incoming requests should pass through it. It’s not just a router; it’s your first line of defense.

Small Business Scenario: If your small business has a serverless API powering your mobile app, an API Gateway can ensure only authenticated users can access certain features. It can also block automated bots attempting to overload your system or scrape data, protecting your service availability and data integrity.

How-to for SMB: Ensure your API Gateway is configured to perform authentication (verifying who is making the request), validate requests (checking if the data looks legitimate), and apply rate limits (preventing too many requests at once, which could be a denial-of-service attack). This significantly reduces the attack surface that reaches your actual functions. Discuss this with your IT team: “Is our API Gateway set up to be a robust security buffer? Does it authenticate users, validate incoming data, and limit suspicious traffic before it hits our core functions?”

Code Example (Conceptual API Gateway Rule):

{ "Path": "/api/data", "Method": "POST", "Authentication": { "Type": "JWT_TOKEN", // Requires a valid JSON Web Token "Issuer": "https://your-identity-provider.com" }, "RequestValidation": { "Schema": "DataInputSchema", // Ensures incoming data matches an expected format "RequiredHeaders": ["Authorization", "Content-Type"] }, "RateLimiting": { "RequestsPerSecond": 10 // Only allow 10 requests per second from one source }, "TargetFunction": "yourLambdaFunction" }

Explanation: This conceptual rule for an API Gateway shows how it can demand a valid authentication token, check if the data being sent matches a predefined safe structure, and limit how often someone can send requests. It acts as a powerful filter, blocking suspicious traffic before it even touches your serverless code.

Expected Output: Only legitimate, authenticated, and properly formatted requests reach your serverless functions, protecting them from many common attacks.

Step 3: Validate All Inputs – Don’t Trust Any Data Entering Your Serverless App

Never assume data coming into your application is safe. Ever. It’s like leaving your front door unlocked because you expect only your friends to visit.

Understand Input Validation Woes: Attackers often try to trick applications by sending malicious or unexpected data—this is what we call “injection attacks” (like SQL injection or Cross-Site Scripting). If your application trusts this bad data, it can be coerced into performing unintended actions, exposing information, or even giving away control.

Small Business Scenario: Imagine your small business website has a serverless function that handles customer contact form submissions. If an attacker submits a message containing malicious code instead of plain text, and your application doesn’t validate it, that code could then be executed when you or another user views the message, potentially compromising your browser or stealing information.

Action: Implement Robust Input Validation and Sanitization: This means every piece of data entering your serverless application—whether it’s from a user form, another service, or an API call—must be thoroughly checked and cleaned.

How-to for SMB: Ensure your developers (or your IT provider) build in strict checks for all incoming data. They should verify that data is in the expected format (e.g., an email address looks like an email, a number is actually a number), within expected ranges, and free of any malicious code. Ask them, “How are we validating and sanitizing all user input to prevent injection attacks and ensure only safe data is processed by our serverless functions?”

Code Example (Conceptual Input Validation Logic in Python):

import re def validate_email(email_address): # Very basic email regex, real-world regex is more complex if not re.match(r"[^@]+@[^@]+\.[^@]+", email_address): raise ValueError("Invalid email format") return email_address def sanitize_text(user_input): # Remove HTML tags to prevent XSS (Cross-Site Scripting) sanitized = user_input.replace("<", "<").replace(">", ">") # More robust sanitization might involve libraries return sanitized def process_user_data(data): try: data['email'] = validate_email(data['email']) data['comment'] = sanitize_text(data['comment']) # Process the now-validated and sanitized data print("Data is safe to process:", data) except ValueError as e: print("Security Error: Invalid input detected:", e) # Example usage: # process_user_data({'email': '[email protected]', 'comment': ''}) # process_user_data({'email': 'bad-email', 'comment': 'hello'})

Explanation: This Python snippet shows how you’d conceptualize checking an email for correct format and “cleaning” text to remove potentially malicious HTML. It’s a foundational step to ensure your serverless functions aren’t fooled by bad data.

Expected Output: Your applications reject or neutralize malicious data, significantly reducing the risk of injection attacks and data corruption.

Step 4: Secure Your Secrets – Keep Passwords and API Keys Out of Sight

Leaving sensitive information like passwords, API keys, and secret tokens directly in your application code is like taping your house key to your front door.

Understand Exposed Secrets Risk: API keys, database passwords, secret tokens—these are your application’s “credentials.” If they’re accidentally exposed or stored insecurely within your application environment (e.g., directly in code, in a public code repository), they become prime targets for attackers. A single exposed secret can grant an attacker wide access to your cloud resources.

Small Business Scenario: Your serverless function needs an API key to send SMS notifications through a third-party service. If that API key is hardcoded into your function’s code and that code somehow becomes publicly visible (e.g., a developer accidentally pushes it to a public GitHub repository), an attacker could steal your key and rack up huge bills sending spam messages from your account.

Action: Use Dedicated Secure Secrets Management Services: All major cloud providers offer specialized services designed to securely store and manage your application’s secrets. These are like highly secure digital vaults.

How-to for SMB: Never embed sensitive data directly into your application code. Instead, insist that your IT team uses your cloud provider’s secure “vaults” or management services (e.g., AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager). These services retrieve secrets only when needed and keep them encrypted and audited. Ask, “How are we managing sensitive information like API keys and database passwords for our serverless apps? Are we using a dedicated secrets manager, or are these secrets stored in plain text or directly in code?”

Code Example (Conceptual Secret Retrieval):

import os # In a real-world scenario, you'd use a cloud SDK (e.g., boto3 for AWS) # to retrieve secrets from a service like AWS Secrets Manager. def get_database_password(): # DO NOT hardcode passwords like this! # Instead, use a secure method to retrieve. # Option 1: From environment variables (better than hardcoding, but still not ideal for very sensitive secrets) # This is a basic example for understanding, secure services are preferred. db_password = os.environ.get('DB_PASSWORD') if not db_password: print("Warning: DB_PASSWORD environment variable not set.") # Fallback or error handling # Option 2 (Preferred): Retrieve from a dedicated secrets management service # This would involve calling the cloud provider's SDK to fetch the secret. # E.g., db_password = secrets_manager_client.get_secret_value(SecretId='my-db-secret')['SecretString'] return db_password # Example usage: # password = get_database_password() # if password: #     print("Database password retrieved (conceptually).") # else: #     print("Failed to retrieve password.")

Explanation: This Python concept shows that passwords shouldn’t be hardcoded. While environment variables are a step up, the ultimate solution is using a cloud provider’s secrets manager, where the code requests the secret securely at runtime without ever having it stored in plain sight.

Expected Output: Sensitive credentials are no longer exposed in your code or configuration files, drastically reducing the risk of unauthorized access due to secret compromise.

Step 5: Maintain Code Health – Updates and Secure Dependencies

Modern applications, especially serverless ones, often rely on pre-built software components. These are a blessing, but they can also be a hidden vulnerability.

Understand Third-Party Dependencies Risk: Your serverless application likely uses various open-source libraries or packages developed by others. If these “borrowed” components have security flaws (and many do, unfortunately), they can become an easy entry point for attackers. This is part of what we call a “supply chain attack,” where vulnerabilities in components you use can compromise your own application.

Small Business Scenario: Your marketing website’s serverless backend uses a popular open-source library to compress images. If a critical security flaw is discovered in that library, and you haven’t updated it, an attacker could potentially exploit it to gain control over your image processing function, or even use it as a stepping stone to other parts of your cloud environment.

Action: Regularly Review Code and Update Dependencies: You need to keep your application’s code clean and ensure all third-party libraries and frameworks are promptly updated.

How-to for SMB: If you have internal or external developers, ensure they follow secure coding practices. Critically, they must regularly check for and apply security updates to any external software components your serverless application uses. This patches known vulnerabilities before attackers can exploit them. Ask your developers, “How often do we scan our serverless application’s dependencies for known vulnerabilities, and how quickly do we apply security updates? Do we have a process for this?”

Code Example (Conceptual Dependency Update Command):

# For Node.js projects: npm audit         # Scans for vulnerabilities npm update        # Updates packages to the latest versions within specified ranges # For Python projects: pip check         # Checks for conflicting dependencies pip list --outdated # Lists outdated packages pip install --upgrade package-name # Upgrades a specific package # For general awareness, not direct code: # Integrate security scanning tools into your development pipeline # to automatically detect vulnerable dependencies.

Explanation: These are common commands used by developers to audit and update their project’s dependencies. While you might not run these yourself, understanding that such tools exist and are crucial for maintaining security is key for your discussions with your IT team.

Expected Output: Your serverless applications are built with fewer known vulnerabilities from third-party components, and your code follows secure development principles, reducing your attack surface.

Step 6: Encrypt Data Everywhere – At Rest and In Transit

Encryption is your digital padlock, protecting your data whether it’s sitting still or moving between systems. It makes sensitive information unreadable to unauthorized eyes.

Action: Encrypt All Sensitive Data: This means data both when it’s stored (at rest, e.g., in a database or storage bucket) and when it’s moving between different systems (in transit, e.g., between your serverless function and a database).

Small Business Scenario: If your e-commerce platform uses serverless functions and a cloud database to store customer credit card numbers (tokenized, of course!), encrypting this data at rest means that even if an attacker manages to access the underlying storage, they will only find scrambled, unreadable information. Encrypting data in transit ensures that details like customer logins are protected as they travel between your website and your serverless login function.

How-to for SMB: Leverage your cloud provider’s built-in encryption features. For storage services (like S3 buckets or databases), ensure encryption at rest is enabled by default. For communication, always verify that your applications use secure, encrypted connections (like HTTPS/TLS) for all internal and external communication. This is non-negotiable for protecting customer data and intellectual property. Ask your provider, “Is all our sensitive data, both stored and in transit, encrypted by default? Are we utilizing TLS/SSL for all network communications?”

Code Example (Conceptual S3 Bucket Encryption):

{ "Bucket": "your-sensitive-data-bucket", "ServerSideEncryptionConfiguration": { "Rules": [ { "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "AES256" // Use AES-256 encryption } } ] } }

Explanation: This JSON snippet represents a setting for an Amazon S3 storage bucket. It mandates that all data uploaded to this bucket must be encrypted at rest using the AES-256 algorithm. Similar settings exist for databases and other storage services across all cloud providers.

Expected Output: Even if an attacker gains access to your storage or intercepts network traffic, the data remains unreadable due to strong encryption, safeguarding your most valuable assets.

Step 7: Monitor for Trouble – Robust Logging and Automated Alerts

Because serverless functions run only for short periods, it can be hard to spot trouble brewing. You need good “security cameras” and a responsive alarm system for your cloud environment.

Understand Limited Visibility: The ephemeral nature of serverless functions (they appear, do their job, then disappear) means traditional monitoring methods often fall short. It’s challenging to maintain continuous oversight and detect subtle malicious activity if you don’t know what to look for.

Small Business Scenario: Imagine an attacker attempting to brute-force a login page powered by a serverless function. Without proper monitoring, you might not notice a sudden surge of failed login attempts until your system is overwhelmed or an account is compromised. Robust logging and alerts would notify you immediately of such suspicious activity, allowing you to react quickly.

Action: Implement Comprehensive Logging and Monitoring: Think of this as installing security cameras and an alarm system for your serverless applications.

How-to for SMB: Utilize your cloud provider’s monitoring tools (e.g., AWS CloudWatch, Azure Monitor, Google Cloud Logging/Monitoring) to collect detailed logs of all activity—every function invocation, every error, every access attempt. Crucially, set up automated alerts for any suspicious behavior, potential errors, or unauthorized access. This way, you’ll be notified immediately if something looks amiss. Ask your IT provider, “Do we have comprehensive logging and monitoring enabled for our serverless applications, with automated alerts for security incidents like unusual error rates or unauthorized access attempts?”

Code Example (Conceptual CloudWatch Alarm Rule for AWS):

{ "AlarmName": "HighErrorRateOnSensitiveFunction", "MetricName": "Errors", "Namespace": "AWS/Lambda", "Statistic": "Sum", "Period": 300, // 5 minutes "EvaluationPeriods": 1, "Threshold": 5, // If more than 5 errors in 5 minutes "ComparisonOperator": "GreaterThanThreshold", "AlarmActions": [ "arn:aws:sns:REGION:ACCOUNT_ID:security-alert-topic" // Send notification to an alert system ], "TreatMissingData": "notBreaching" }

Explanation: This conceptual alert rule monitors a specific serverless function. If it encounters more than 5 errors within a 5-minute period, it triggers an alarm, sending a notification to your security team or IT provider. This proactive monitoring helps detect issues like misconfigurations, resource exhaustion, or even attempted denial-of-service attacks.

Expected Output: You gain vital visibility into your serverless environment, enabling rapid detection and response to security incidents or operational issues, minimizing their impact.

Step 8: Smart Cloud Configurations – The Baseline of Serverless Security

Default settings aren’t always the most secure. You wouldn’t leave your new house with the builder’s default locks, would you?

Understand Misconfigurations: Simple incorrect settings or overlooked configurations within your cloud services can inadvertently expose sensitive data or allow unauthorized access to your functions. These “oops, I left the door open” moments are incredibly common causes of breaches.

Small Business Scenario: A developer accidentally sets a storage bucket containing customer invoices to be “publicly accessible” instead of private. Without active review of cloud configurations, this sensitive data could be exposed to anyone on the internet, leading to a severe data breach and reputational damage. Proactively reviewing and hardening these settings is critical.

Action: Actively Configure Cloud Services Securely from the Outset: Don’t just rely on default settings, which might prioritize ease of use over security.

How-to for SMB: Work closely with your cloud provider or IT specialist to ensure that all serverless-related services (like storage buckets, databases, and network settings) have appropriate, secure configurations. This means ensuring storage buckets aren’t publicly accessible unless absolutely necessary, databases require strong authentication, and network access is tightly controlled. Regularly audit these configurations. Ask, “Are we actively reviewing and hardening the default security configurations of all our cloud services used by serverless applications? Are our storage buckets and databases properly secured and not publicly exposed?”

Code Example (Conceptual S3 Public Access Block Policy):

{ "BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true }

Explanation: This JSON represents a common configuration for an Amazon S3 bucket (or similar storage in other clouds) that explicitly blocks all forms of public access. This is a critical setting to prevent accidental data exposure, which has been a source of many high-profile breaches. Ensuring these kinds of settings are enabled for any sensitive data storage is a smart configuration practice.

Expected Output: Your cloud environment’s baseline security is strong, eliminating common vulnerabilities that arise from insecure default settings and significantly reducing the risk of accidental data exposure.

Step 9: Set Function Timeouts – Preventing Resource Abuse in Serverless

Just like you wouldn’t let a plumber work indefinitely on an hourly rate without a time limit, your serverless functions need constraints too.

Action: Configure Appropriate Timeout Limits for Your Serverless Functions: Every serverless function should have a maximum execution time defined.

Small Business Scenario: A serverless function designed to process images should take a few seconds at most. If an attacker manages to trick that function into an infinite loop or a very long, resource-intensive calculation, it could run for minutes, racking up significant cloud bills and potentially denying service to legitimate users. Setting a timeout ensures it stops after a reasonable duration.

How-to for SMB: Ensure that your functions are set to stop executing after a reasonable period that’s just long enough to complete their intended task. This prevents malicious actors from running functions indefinitely to consume resources (leading to higher bills and potentially Denial of Service) or to prolong an attack while trying to exfiltrate data. It’s a simple yet effective control. Ask your IT team, “Are appropriate timeout limits configured for all our serverless functions? What is the rationale behind these timeout values?”

Code Example (Conceptual Function Timeout Setting for AWS Lambda):

# For an AWS Lambda function (in a serverless.yml file, for example) functions: myProcessorFunction: handler: handler.main runtime: python3.9 timeout: 30 # Function will terminate after 30 seconds if still running

Explanation: This YAML snippet (a common configuration format) shows a timeout setting for a serverless function. Here, it’s set to 30 seconds. If the function tries to run longer than this, the cloud provider will automatically stop it, preventing resource abuse or runaway processes.

Expected Output: Your serverless functions are protected against prolonged execution, mitigating resource exhaustion attacks and containing the scope of potential incidents, saving you money and protecting availability.

Expected Final Result: A Fortified Serverless Environment for Your Small Business

By diligently working through these steps, whether by implementing them yourself or ensuring your IT partners do, you’ll have a serverless application environment that is significantly more secure. You’ll gain peace of mind knowing that you’ve addressed common vulnerabilities, established robust defenses, and implemented proactive monitoring. This translates into better protection for your business data, customer information, and overall digital reputation.

Troubleshooting Serverless Security: Common Issues & Solutions for SMBs

• Issue: Overwhelmed by Technical Jargon and Complexity:

  • Solution: You’re not alone! Remember, your job as an SMB owner isn’t to become a cloud security engineer. Your role is to understand the risks and the importance of these solutions. Focus on asking the right questions to your IT provider or cybersecurity consultant. Use this guide to help structure those conversations and ensure your concerns are addressed.

• Issue: Difficulty Tracking All Security Configurations:

  • Solution: Ask your IT provider to provide regular, simplified reports on your security posture. Consider using Cloud Security Posture Management (CSPM) tools if your budget allows—these automatically scan your cloud environment for misconfigurations and provide a clear overview. Even a simple spreadsheet tracking key configurations and review dates can be a start for smaller operations.

• Issue: Limited Budget or In-house Expertise:

  • Solution: Start with the highest-impact, lowest-cost actions: least privilege, input validation, and secure secrets management are fundamental and often yield the biggest security improvements for minimal investment. Prioritize. For more complex needs, consider engaging a specialized cybersecurity consultant or a Managed Security Service Provider (MSSP) that focuses on cloud security. They can offer expertise without requiring a full-time hire.

What You Learned: Mastering Serverless Security Fundamentals

You’ve navigated a crucial aspect of modern cybersecurity! We’ve demystified serverless, clarified your shared responsibility in the cloud, and walked through nine practical steps to fortify your serverless applications. You now understand the importance of least privilege, API gateways, input validation, secure secrets management, keeping dependencies updated, data encryption, robust monitoring, smart cloud configurations, and function timeouts. This knowledge empowers you to protect your digital assets more effectively.

Next Steps: Continuing Your Serverless Security Journey

Security is an ongoing journey, not a destination. Here are some critical organizational best practices for SMBs to continue strengthening your posture:

• Employee Training: Your First Line of Defense: Remember that even with the best technical controls, human error can be a weak link. Reinforce general cybersecurity awareness training (phishing, strong passwords, suspicious links) across your team, as employees often interact with applications that utilize serverless backends.
• Regular Security Reviews: A Continuous Process: Don’t treat security as a one-time setup. Periodically review your serverless application’s security posture. Even if it’s just a high-level check-in with your IT team or provider, make it a regular habit.
• Partnering with Experts: When to Call for Help: For complex serverless architectures, or if your in-house expertise is lacking, engaging a cybersecurity consultant or a managed security service provider (MSSP) specializing in cloud security is a wise and often necessary investment. They can provide audits, penetration testing, and ongoing management.

Serverless computing offers incredible benefits to small businesses—agility, cost-efficiency, and scalability are just a few. But these benefits come with a non-negotiable need for proactive and robust security measures. By taking these practical, simplified steps, you’re not just protecting your applications; you’re safeguarding your business, your customer trust, and your future in an increasingly cloud-native world.

Try it yourself and share your results! Follow for more tutorials.