Serverless, Queues and CDN Origin Exposure

Event-driven infrastructure moves the trust decision away from the request. Something else wrote the message, and the consumer often treats it as trusted input.

AWS Lambda

A serverless function is small on disk and large in trust. It often carries a role, secrets and network access sufficient to perform real work. Lambda executes code under an execution role and may use layers, environment variables, VPC networking and event sources. Permissions such as UpdateFunctionCode, UpdateFunctionConfiguration or PassRole may create indirect escalation. I map the role, environment variables, layers, triggers, code-signing configuration and who can update the function. Environment secrets may be encrypted at rest while still being available in plaintext to the authorized runtime. Least privilege on the role remains central.

aws lambda get-function --function-name lab-fn
aws lambda get-function-configuration --function-name lab-fn

SQS and Queue-Based Attack Paths

A queue separates producer and consumer in time. It also separates malicious input from the privileged process that may interpret it later. SQS controls SendMessage, ReceiveMessage, DeleteMessage and queue policy. Consumers interpret message bodies with application logic. A principal with SendMessage may influence a worker holding stronger credentials. Deserialization and command construction issues appear in consumers. I map producers, consumers, expected schema, DLQ behavior and IAM roles on both sides. Permission to send messages is expected in many systems. The finding appears when a consumer trusts the body for an action that needs separate validation.

aws sqs get-queue-attributes --queue-url <url> --attribute-names All

Serverless Across AWS, Azure and GCP

Serverless removes servers from the developer inventory. Permissions, events and supply-chain risks remain. Lambda, Azure Functions and Cloud Functions execute code from events using provider-managed identities. Public triggers, environment secrets, IAM roles, deployment packages and VPC access form the primary surface. I map triggers, runtime identity, code source, secrets and downstream resources before testing input. OS patching may be provider-managed, while application vulnerabilities and overprivileged identities remain customer responsibility.

trigger -> runtime identity -> network -> downstream resources -> deployment source

CDN Origin Exposure and Origin Bypass

A CDN may protect the edge while leaving the origin publicly reachable without the WAF, rate limit or access policy. Origins may appear in DNS history, certificates, headers, cloud metadata and alternate hostnames. Direct access may bypass bot management, DDoS controls, geographic restrictions and cache normalization. I identify origins only through authorized sources and test the correct Host header against suspected IPs or hostnames without touching third parties. A public origin may be architecturally required. Remediation commonly restricts CDN source addresses or requires mTLS or a shared edge-to-origin secret.

curl -k --resolve app.example.com:443:203.0.113.50 https://app.example.com/ -I

References

• Lambda security
• SQS security
• Azure Functions security
• Cloud Run functions security