Hardening Exposed Cloud Functions: A Capybara’s Guide

Serverless functions are like capybaras—they’re everywhere, friendly, and often left exposed to the swamp. Mandiant’s latest research shows that many publicly accessible cloud functions lack authentication, making them prime targets for attackers. Let’s dive into the risks and how to harden your serverless deployments before a caiman takes a bite.

The Risks of Exposed Serverless Functions

Serverless functions, whether on Google Cloud Run or other platforms, can contain vulnerabilities in custom code or third-party packages. Common attacks include Local/Remote File Inclusion (LFI/RFI) and Command Injection. A successful exploit can give an attacker full control over the container, potentially leading to a complete cloud environment takeover.

Attack Scenario: Local File Inclusion

Consider a Python/Flask function that accepts a user-controlled file parameter without validation. An attacker can use directory traversal to read sensitive files like /etc/passwd or source code containing hardcoded secrets.

curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd"}'

Attack Scenario: Command Injection

If a function uses subprocess.run with unsanitized input, an attacker can execute arbitrary commands. For example, they can extract the service account’s bearer token from the metadata server:

curl -X POST https://cloudrun02-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d "{"input": "curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'"}"

With that token, an attacker can impersonate the service account and potentially take over the entire GCP project if it has broad permissions.

Hardening Your Serverless Swamp

Mandiant recommends a multi-layered approach to secure serverless functions. Here are the key strategies:

1. Secure Software Development Lifecycle (S-SDLC)

Integrate security scanning, code review, and least-privilege IAM into your CI/CD pipelines. For AI-generated code (“vibe coding”), isolate experimentation in sandboxed environments and enforce strict data egress controls.

2. Segregate Public Services

Host public-facing Cloud Run services in a dedicated, isolated Google Cloud project. This limits blast radius if a function is compromised.

3. Identity and Access Management (IAM)

Use custom service accounts with least privilege. For example, grant Storage Object Viewer only on the specific bucket needed, and Secret Manager Secret Accessor only on individual secrets.

4. Layer 7 Application Load Balancer (ALB) Architecture

Restrict ingress to internal-only and use an external ALB with Cloud Armor WAF. This provides centralized traffic management, WAF rules, rate limiting, and logging.

5. Web Application Firewall (WAF) with Cloud Armor

Use preconfigured WAF rules to block LFI and RCE attacks. For example:

evaluatePreconfiguredWaf('lfi-v33-stable', {'sensitivity': 3})

This blocks path traversal requests like ../../../etc/passwd with a 403 Forbidden.

6. Serverless Architecture Controls

Use VPC Service Controls to restrict lateral movement and data exfiltration when using VPC connectors.

Conclusion

Serverless functions drive agility, but don’t let your capybara swim without armor. Implement defense-in-depth with proper IAM, WAF, and network segmentation. For more on securing your cloud, check out our Google Cloud review and Cloudflare Workers review.

Original announcement published on Google Cloud.