This chapter covers serverless security considerations, a critical topic for the SY0-701 exam under Domain 3.0 (Security Architecture), Objective 3.6. Serverless computing shifts security responsibilities to the cloud provider for the infrastructure, but you must still secure the application code, data, and access controls. Understanding these nuances is essential for passing the Security+ exam and for real-world cloud security roles.
Jump to a section
Imagine a vending machine in a busy office. The machine dispenses snacks, but it has no internal inventory or stock—it contacts a remote warehouse every time someone makes a selection. The warehouse prepares the snack, sends it, and the machine just passes it to the customer. This is a serverless function: the machine (cloud provider) runs code (vending logic) only when triggered, scaling instantly if many people order at once. Security concerns: if someone tampers with the machine's communication (eavesdropping on API calls), they could intercept the order and redirect it to a malicious snack. If the warehouse doesn't authenticate the machine properly, an attacker could impersonate the machine and order snacks for free (injection attacks). Also, if the machine's code has a bug (e.g., it doesn't check the snack selection properly), an attacker could request a 'free' snack by sending a specially crafted order (input validation failure). The security guard (you) must ensure the machine's communication is encrypted (TLS), the warehouse verifies the machine's identity (API keys, OAuth), and the machine's code is reviewed (static analysis) and has minimal permissions (least privilege). In serverless, you don't manage servers, but you must secure the code, the triggers, and the data flowing in and out.
What is Serverless Computing?
Serverless computing is a cloud execution model where the cloud provider dynamically manages the allocation of machine resources. The term 'serverless' is a misnomer—servers still exist, but they are abstracted away from the developer. The most common form is Function-as-a-Service (FaaS), where code runs in stateless containers that are triggered by events (e.g., HTTP requests, database changes, file uploads). AWS Lambda, Azure Functions, and Google Cloud Functions are leading examples.
The Shared Responsibility Model in Serverless
In traditional IaaS, you manage the OS, runtime, and application. In serverless, the provider manages the OS, runtime, and scaling—you only manage the code and configuration. However, security responsibilities are still shared:
Provider responsibilities: Physical security, hypervisor, network infrastructure, runtime isolation, and availability of the platform.
Your responsibilities: Code security (vulnerabilities, dependencies), function configuration (permissions, triggers), data protection (encryption in transit and at rest), and identity management (who can invoke functions).
The SY0-701 exam emphasizes that you must understand this boundary to avoid misconfigurations.
Attack Surface in Serverless
Serverless introduces unique attack vectors:
Event Injection: Attackers can manipulate event sources (e.g., HTTP headers, S3 object metadata) to inject malicious data that the function processes unsafely. For example, a function that parses JSON from an S3 event could be exploited via a crafted object.
Insecure Dependencies: Functions often use third-party libraries (e.g., npm packages, Python modules). A vulnerable library can lead to code execution or data leakage.
Function Permissions Over-provisioning: Functions often have IAM roles with excessive permissions. If an attacker exploits a function vulnerability (e.g., SSRF), they can use those permissions to access other resources (e.g., read secrets from a database).
Denial of Service (DoS): Serverless scales automatically, but attackers can trigger many invocations to exhaust your account's concurrency limits or cause unexpected costs (resource exhaustion).
Insecure Secrets Management: Developers may hardcode API keys or database connection strings into function environment variables, which can be exposed through logs or error messages.
How Serverless Security Works Mechanically
Let's step through a typical serverless function invocation to see where security controls apply:
Trigger: An event source (e.g., API Gateway, S3 bucket, CloudWatch timer) invokes the function. The trigger must be authenticated. For example, an HTTP API Gateway can require an API key or OAuth token.
Execution Environment: The provider spins up a container (or reuses a warm one) with the function code. The container is isolated using cgroups and namespaces, but side-channel attacks are possible (e.g., Spectre, Meltdown) though rare.
Function Code: The code executes with a specific IAM role (in AWS, an execution role). The role determines what AWS resources the function can access (e.g., read from DynamoDB, write to S3).
Data Processing: The function may read from databases, call external APIs, or write to storage. All data in transit should use TLS. Data at rest should be encrypted (e.g., S3 SSE, DynamoDB encryption).
Logging and Monitoring: All invocations are logged to services like AWS CloudWatch, Azure Monitor, or Google Cloud Logging. Logs can contain sensitive data if not sanitized.
Key Components and Standards
IAM Roles (AWS) / Managed Identities (Azure): Every function should have a least-privilege role. For example, if a function only needs to read from a specific DynamoDB table, its role should only allow dynamodb:GetItem on that table.
VPC Configuration: Functions can be placed inside a VPC to access private resources (e.g., RDS databases). However, this requires a VPC endpoint or NAT gateway, which adds complexity and cost. Misconfiguration can lead to data exposure.
Secrets Manager / Parameter Store: Use cloud-native secrets management to store API keys, database passwords, etc. For example, AWS Lambda can retrieve secrets from AWS Secrets Manager at runtime.
API Gateway: Often used as a trigger for HTTP functions. It can throttle requests, validate input (e.g., JSON schema), and authenticate via Cognito or Lambda authorizers.
OWASP Serverless Top 10: The OWASP project provides a list of top serverless vulnerabilities, including injection, broken authentication, and insecure deployment.
How Attackers Exploit Serverless
Attackers often target the following:
Event Injection via HTTP: Sending malicious payloads in request headers, query strings, or body. For example, a function that logs user input without sanitization could be hit with CRLF injection to manipulate logs.
SSRF (Server-Side Request Forgery): If a function makes HTTP requests to external URLs based on user input, an attacker can make it request internal services (e.g., AWS metadata endpoint http://169.254.169.254/latest/meta-data/) to steal IAM credentials.
Dependency Confusion: Uploading a malicious package to a public repository with the same name as a private package used by the function, causing the function to pull the malicious version.
Resource Exhaustion: Triggering thousands of function invocations to cause financial denial of service (FDoS). Without proper rate limiting and budget alerts, this can run up huge bills.
Countermeasures
Input Validation: Validate and sanitize all inputs at the function entry point. Use a whitelist approach (accept known good) rather than blacklist.
Least Privilege: Grant only the permissions needed. Regularly audit and rotate IAM roles.
Secrets Management: Never hardcode secrets. Use environment variables with encryption (e.g., AWS Lambda environment variables can be encrypted with KMS).
Rate Limiting: Use API Gateway throttling or cloud provider rate limits to prevent abuse.
Vulnerability Scanning: Scan dependencies using tools like Snyk, OWASP Dependency-Check, or cloud-native services (e.g., AWS Inspector).
Monitoring and Alerting: Set up logging of all invocations and alerts for unusual patterns (e.g., sudden spike in error rates or invocation count).
Real Command/Tool Examples
- AWS CLI to update Lambda function configuration to use a VPC:
aws lambda update-function-configuration --function-name my-function --vpc-config SubnetIds=subnet-123,subnet-456,SecurityGroupIds=sg-789- Azure CLI to add a managed identity to a function app:
az functionapp identity assign --name MyFunctionApp --resource-group MyResourceGroup- Scanning dependencies with Snyk:
snyk test --file=requirements.txt- Encrypting environment variables in AWS Lambda:
aws lambda update-function-configuration --function-name my-function --environment Variables={DB_PASSWORD=mysecret} --kms-key-arn arn:aws:kms:us-east-1:123456789012:key/abc123Identify the Trigger Source
The first step in securing a serverless function is identifying all possible triggers. Common triggers include HTTP requests via API Gateway, file uploads to S3, database changes (e.g., DynamoDB Streams), and scheduled events (CloudWatch Events). Each trigger has its own authentication and authorization mechanisms. For example, S3 events can be configured to require a specific bucket policy, while API Gateway can use IAM authorization or Cognito User Pools. A common mistake is assuming all triggers are trusted. Attackers can send events from unexpected sources (e.g., a malicious S3 object with crafted metadata). You must verify that the event source is authenticated and that the event payload is validated. Tools like AWS CloudTrail can log all API calls that invoke functions, helping you audit trigger usage.
Harden the Function Code
The function code is the primary attack surface. Write code that validates all inputs, avoids dangerous functions (e.g., `eval` in Python, `child_process.exec` in Node.js), and uses parameterized queries for database access. Use a static application security testing (SAST) tool like SonarQube or cloud-native services (e.g., AWS CodeGuru) to scan for vulnerabilities. Also, minimize dependencies; each library adds potential vulnerabilities. Use a software composition analysis (SCA) tool to track known vulnerabilities in dependencies. For example, if you use a vulnerable version of `lodash`, an attacker could exploit prototype pollution. Always keep dependencies updated and pin versions to avoid automatic updates that might introduce breaking changes or vulnerabilities.
Apply Least Privilege Permissions
Assign the function an IAM role with only the permissions it needs. For example, if the function only reads from a specific DynamoDB table, its role should allow only `dynamodb:GetItem` on that table ARN. Avoid using wildcards (`*`) in resource ARNs. Also, restrict the actions to only those required. For example, if the function only needs to write to S3, do not grant `s3:GetObject` or `s3:ListBucket`. Use AWS IAM Access Analyzer or Azure AD Privileged Identity Management to review and tighten permissions. Over-provisioned roles are a common finding in audits. An attacker exploiting an SSRF vulnerability in the function could use the over-permissive role to access other resources, such as reading secrets from Parameter Store or deleting DynamoDB tables.
Secure Secrets and Configuration
Never hardcode secrets like database passwords, API keys, or encryption keys in the function code or environment variables. Instead, use a secrets manager service: AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager. Retrieve secrets at runtime using the provider's SDK. For example, in AWS Lambda, use `boto3.client('secretsmanager')` to fetch a secret. Ensure that the function's IAM role has permission to access the secrets manager (e.g., `secretsmanager:GetSecretValue`). Also, encrypt environment variables using KMS. Regularly rotate secrets. A common mistake is leaving plaintext secrets in environment variables visible in the console or logs. Enable CloudWatch Logs encryption and avoid logging sensitive data.
Implement Monitoring and Alerting
Set up logging for all function invocations using CloudWatch Logs (AWS), Application Insights (Azure), or Cloud Logging (GCP). Monitor for anomalous patterns: high invocation rates (possible DoS), error spikes (exploitation attempts), or unusual data access (e.g., reading from an unexpected S3 bucket). Use metrics like invocation count, duration, and throttles. Set up alarms: for example, if invocation count exceeds 1000 per minute, send an alert to a security team via SNS or email. Also, enable AWS CloudTrail or Azure Activity Log to track administrative actions on function configurations (e.g., changes to IAM roles or environment variables). A common mistake is not monitoring at all, allowing an attacker to exfiltrate data for days before detection.
Scenario 1: Data Exfiltration via Over-Permissive IAM Role
A financial services company deploys a serverless function that processes loan applications. The function reads from an S3 bucket containing uploaded documents, calls an external credit API, and writes results to a DynamoDB table. The developer assigns the function an IAM role with s3:* and dynamodb:* permissions to 'make it work quickly'. An attacker discovers an SSRF vulnerability in the function (the function takes a URL parameter and fetches it). The attacker makes the function request the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/) and retrieves the temporary IAM credentials. With those credentials, the attacker can list all S3 buckets and download sensitive customer documents. The correct response would be to immediately revoke the compromised credentials, audit the function's IAM role to apply least privilege (e.g., s3:GetObject on the specific bucket, dynamodb:PutItem on the specific table), and fix the SSRF vulnerability by validating the URL parameter against an allowlist. A common mistake is only patching the SSRF without reviewing permissions, leaving other functions vulnerable.
Scenario 2: Dependency Vulnerability Leading to RCE
A healthcare startup uses a serverless function that processes patient data. The function uses an outdated version of a popular npm package (e.g., lodash@4.17.15) that has a known prototype pollution vulnerability (CVE-2019-10744). An attacker sends a crafted JSON payload in an HTTP request that exploits the vulnerability to execute arbitrary code on the function's container. The attacker then uses the function's IAM role (which has s3:PutObject on a bucket) to upload a malicious script to the bucket, which then infects other systems. The correct response is to update the package to a patched version, scan the codebase with Snyk or similar tools, and implement input validation to reject unexpected JSON keys. A common mistake is relying only on runtime protection (e.g., AWS WAF) without addressing the root cause—the vulnerable dependency.
Scenario 3: Financial DoS via Unthrottled API
An e-commerce company uses API Gateway to trigger a serverless function for checkout processing. The API has no rate limiting or throttling. An attacker scripts thousands of requests per second, causing the function to scale massively. The company's AWS bill spikes to $50,000 in one hour before they notice. The correct response is to immediately block the attacker's IP, enable API Gateway throttling (e.g., 100 requests per second per key), set up AWS Budgets alerts for cost anomalies, and implement a Web Application Firewall (WAF) with rate-based rules. A common mistake is assuming the cloud provider will automatically cap costs; they do not—you must configure budgets and alerts proactively.
What SY0-701 Tests on This Objective
Objective 3.6 covers 'Given a scenario, implement and maintain security controls for cloud and virtualization technologies.' Under this, serverless security appears as a subset. The exam expects you to:
Understand the shared responsibility model in serverless: what the provider secures (runtime, infrastructure) vs. what you secure (code, configuration, data).
Identify common serverless security risks: event injection, insecure dependencies, over-privileged roles, DoS, and secrets exposure.
Recommend controls: input validation, least privilege, secrets management, rate limiting, and monitoring.
Distinguish serverless from other cloud models (IaaS, PaaS) in terms of security responsibilities.
Common Wrong Answers and Why Candidates Choose Them
'Serverless means no servers, so no security responsibilities.' Candidates confuse the abstraction with complete security delegation. Reality: You still secure the code, data, and access.
'The provider automatically encrypts all data and manages secrets.' The provider may offer encryption options, but you must enable them (e.g., enable S3 encryption, use KMS). Secrets management is your responsibility.
'You don't need to patch serverless functions because the provider updates the runtime.' While the provider patches the runtime, you must update your own dependencies and code. Vulnerabilities in your code or libraries are your responsibility.
'Serverless functions are immune to DoS because they scale infinitely.' They scale, but at a cost. Without throttling, an attacker can cause financial DoS.
Specific Terms and Acronyms on the Exam
FaaS (Function as a Service): The core serverless model.
Event source: The trigger that invokes the function (e.g., S3, API Gateway, DynamoDB Streams).
Execution role / Managed identity: The IAM role assigned to the function.
Cold start: The latency when a function is invoked after being idle; not a security issue but may appear in context of performance.
OWASP Serverless Top 10: A reference for vulnerabilities.
CWPP (Cloud Workload Protection Platform): A tool for securing serverless workloads.
Common Trick Questions
'Which of the following is a serverless security responsibility of the customer?' Options: Patching the hypervisor, securing the runtime, securing the function code, managing physical servers. Correct: securing the function code. (The provider patches the hypervisor and runtime; there are no physical servers.)
'What is the primary risk of using a third-party library in a serverless function?' Options: Increased latency, licensing costs, supply chain vulnerability, cold start. Correct: supply chain vulnerability.
'How can an attacker exploit a serverless function that processes user input?' Options: Buffer overflow, event injection, SQL injection, DDoS. Correct: event injection (though SQL injection is possible if the function queries a database unsafely, event injection is more specific to serverless).
Decision Rule for Eliminating Wrong Answers
On scenario questions, first identify the cloud model (IaaS, PaaS, serverless). If serverless, eliminate any answer that implies managing servers (e.g., 'patch the OS,' 'install antivirus'). Next, look for answers that shift all responsibility to the provider—these are usually wrong. Finally, focus on code-level controls: input validation, least privilege, and secrets management are almost always correct for serverless scenarios.
Serverless shifts infrastructure security to the provider, but you are responsible for code, data, and access controls.
Common serverless risks include event injection, insecure dependencies, over-privileged roles, DoS, and secrets exposure.
Implement input validation, least privilege IAM roles, secrets management, rate limiting, and monitoring.
Use cloud-native tools like AWS Secrets Manager, Azure Key Vault, and AWS CloudTrail for security.
The OWASP Serverless Top 10 is a key reference for vulnerabilities.
Always enable encryption for data at rest (e.g., S3 SSE) and in transit (TLS).
Regularly scan dependencies for known vulnerabilities using SCA tools.
These come up on the exam all the time. Here's how to tell them apart.
Serverless (FaaS)
No server management; provider handles OS and runtime.
Scales automatically per invocation.
Billed per execution (request and duration).
Stateless; state must be stored externally.
Security focus: code, dependencies, permissions.
IaaS (Virtual Machines)
You manage OS, patches, and runtime.
Manual scaling or auto-scaling groups.
Billed per hour regardless of usage.
Stateful; you can store data on the VM disk.
Security focus: OS hardening, network security, patching.
Mistake
Serverless means no servers, so there are no security threats.
Correct
Servers exist but are managed by the provider. Security threats still apply to the code, data, and configuration. You must secure the function code, dependencies, permissions, and data.
Mistake
The cloud provider automatically encrypts all data at rest and in transit.
Correct
Encryption is often optional and must be explicitly configured. For example, S3 bucket encryption is not enabled by default. You must enable server-side encryption (SSE) or use KMS.
Mistake
Serverless functions are stateless, so they can't be exploited for data exfiltration.
Correct
Stateless means no persistent local storage, but functions can still access external services (databases, storage buckets) and exfiltrate data via network calls.
Mistake
Since the provider scales functions automatically, you don't need rate limiting.
Correct
Automatic scaling can lead to resource exhaustion and financial DoS. Rate limiting (via API Gateway or cloud WAF) is essential to prevent abuse.
Mistake
You don't need to patch serverless functions because the provider updates the runtime.
Correct
The provider updates the runtime, but you must update your own code and third-party dependencies. Vulnerabilities in your libraries are your responsibility.
In serverless, the cloud provider is responsible for the physical infrastructure, runtime, and platform availability. The customer is responsible for the function code, dependencies, configuration (IAM roles, triggers, environment variables), and data protection (encryption, access controls). The exam tests that you know this boundary: you don't patch the OS, but you must secure your code and secrets.
Attackers exploit event injection (malicious input), insecure dependencies (vulnerable libraries), over-privileged IAM roles (to access other resources), and lack of rate limiting (financial DoS). For example, an SSRF vulnerability in a function can be used to steal IAM credentials from the metadata endpoint. Always validate inputs and apply least privilege.
PaaS (e.g., Google App Engine) provides a platform to deploy applications, but you still manage the application code and sometimes the runtime configuration. Serverless (FaaS) abstracts the runtime even further—you only provide individual functions. Security responsibilities are similar: you secure the code and data. However, serverless functions are more granular and have a smaller attack surface per function.
Use a cloud secrets manager (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) to store secrets like API keys and database passwords. Retrieve them at runtime using the provider's SDK. Never hardcode secrets in code or environment variables. Ensure the function's IAM role has permissions to access the secrets manager. Also, enable encryption for environment variables using KMS.
Event injection occurs when an attacker manipulates the event source data (e.g., HTTP headers, S3 object metadata) to inject malicious input that the function processes unsafely. For example, if a function logs user input without sanitization, an attacker could inject CRLF characters to manipulate log entries. Countermeasures include input validation, sanitization, and using parameterized queries.
Implement rate limiting at the API Gateway level (e.g., 100 requests per second per API key), use cloud WAF with rate-based rules, set up AWS Budgets alerts for cost anomalies, and configure function concurrency limits to prevent runaway scaling. Also, monitor invocation patterns and set alarms for unusual spikes.
It is a list of the top ten security risks specific to serverless applications, published by OWASP. It includes risks like injection, broken authentication, insecure deployment, over-privileged function permissions, and insecure secrets storage. The exam may reference it as a resource for identifying serverless vulnerabilities.
You've just covered Serverless Security Considerations — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?