Function Event-Data Injection is the serverless form of the classic injection weakness: untrusted data reaches an interpreter (a SQL engine, a shell, an eval, an XML parser, an outbound HTTP client, or a log sink) and is treated as instructions rather than data. What makes it distinct in serverless is where the untrusted data comes from.

Broken Authentication in a serverless application is the failure to consistently and correctly verify who (or what) is invoking a function, across every way that function can be reached. It is not a single missing login form-it is the gap that opens when a highly distributed, stateless collection of functions is protected in some places and left open in others.

Insecure Serverless Deployment Configuration occurs when the many settings that govern serverless functions-and the cloud resources they depend on-are left at insecure defaults or actively misconfigured. A single function is rarely deployed alone: it arrives with an execution role, environment variables, triggers, a possible public URL, and a web of buckets, queues, topics, tables, and API Gateway routes around it.

Over-Privileged Function Permissions & Roles occurs when a serverless function is granted far more identity and access management (IAM) permission than it actually needs to do its job. Instead of being scoped to the one table it reads or the one bucket it writes, the function carries wildcard actions, wildcard resources, broad managed policies, or a single shared role reused across the whole application.

Inadequate Function Monitoring and Logging occurs when a serverless application cannot see what its own functions are doing well enough to notice an attack. The individual functions may be correctly written, but the platform around them emits only shallow, operational logs-so injection attempts, credential abuse, reconnaissance, data exfiltration, and cost-driven abuse spread across many short-lived invocations without ever surfacing an alert.

Insecure Third-Party Dependencies occur when a serverless function pulls in external code-npm, PyPI, Maven, or Gradle packages, plus their transitive dependencies-that is vulnerable, malicious, unmaintained, or simply unaccounted for. The function's own code may be a few dozen lines, yet the deployment package it runs is dominated by libraries the author never wrote and often never read.

Insecure Application Secrets Storage occurs when the many secrets a serverless function needs to do its job-database credentials, third-party API keys, signing keys, OAuth client secrets, session tokens, encryption keys-are kept somewhere that is convenient for the developer but readable by an attacker. The function may be otherwise well written, but its secrets sit in plaintext environment variables, hardcoded in source committed to Git, baked into the deployment artifact, or written into the infrastructure-as-code that lives in the repository.

Denial of Service & Financial Resource Exhaustion is what happens when the two properties that make serverless attractive-it scales automatically and you pay per use-are turned against you. Because functions scale out on demand, an attacker can exhaust the finite concurrency your account or region is allowed and starve legitimate traffic (a classic denial of service).

Serverless Business Logic Manipulation is the abuse of an application's intended flow. A serverless application is rarely one program: it is many small functions chained together by events, queues, topics, and orchestration-Step Functions, SQS/SNS, EventBridge, DynamoDB Streams.

Improper Exception Handling and Verbose Error Messages occurs when a serverless function lets an exception decide its own fate: the error bubbles up unhandled, the platform serialises whatever it can, and the caller receives a response full of internal detail-or the function fails in a way that quietly skips a security check, half-completes a write, or vanishes without leaving an audit record. It is not one broken line; it is the accumulated consequence of thousands of small, quickly-written functions that were never given a deliberate answer to the question "what should happen when this goes wrong?"