Skip to content
Paul Marinos
Menu

API & Cloud-Native AppSec

Where application security meets the platform — the OWASP API Top 10, container and image security, and IaC scanning that catches the flaw before it deploys.

Application security and infrastructure security stopped being separable somewhere around the move to containers and declarative infrastructure. The application is a container image; its permissions are IaC; its front door is an API gateway. The bug that used to be a server misconfiguration is now a line in a Terraform file that ships through the pipeline with the code.

This is the seam between AppSec and cloud security, and it’s the placeholder the site structure marks for expansion.

APIs need their own list because the risk profile genuinely differs from the web app list, and the difference is concentrated at the top: the two highest-ranked API risks are both authorization.

  • Broken Object-Level Authorization (BOLA/IDOR) — the dominant API vulnerability. The API returns an object by id without checking the caller owns it. Nearly invisible in code, since the broken version looks complete, and the API surface makes it systematic to test — every parameterized endpoint, every other user’s identifiers.
  • Broken Function-Level Authorization — admin endpoints reachable with non-admin tokens, usually just undocumented rather than protected.
  • Broken Object Property-Level Authorization — mass assignment (the client sets fields it shouldn’t, like role) and excessive data exposure (the response includes fields the UI hides but the API returns).

The pattern across all three: the UI enforced authorization and the API doesn’t. When the client was the only caller, hiding a button was a control; against direct API access it’s nothing. This is the same finding API pentesting leads with, and the fix is server-side authorization on every object and function, not client-side concealment.

A container image is a filesystem plus metadata, and its security decomposes cleanly:

  • Base image. Most vulnerabilities in a scanned image come from the base, not your code. Minimal or distroless images carry less to be vulnerable — a smaller image is a smaller attack surface, literally.
  • Image scanning for known-vulnerable OS and language packages, in the pipeline before push. This is SCA pointed at the image, and reachability matters just as much — a vulnerable package that never runs is noise.
  • No secrets in images. Build args and layers persist; a secret added and removed across layers is still in the history, the same failure as git.
  • Run as non-root, read-only root filesystem, dropped capabilities. Defense in depth for when the app is compromised — this is the build-time half of the Kubernetes hardening the platform enforces at runtime.

The division of labour: the image is an AppSec artifact built in the pipeline; the runtime that runs it is cloud-infrastructure security. Admission control is where they meet — the cluster refusing an image that fails policy.

When infrastructure is code, its misconfigurations are catchable before they exist — a public S3 bucket or an over-permissive security group is a reviewable diff, not a runtime discovery.

  • Scan IaC in the pipeline — Terraform, CloudFormation, Bicep — with tools like Checkov, tfsec or Terrascan. Catch the public bucket, the wildcard IAM policy, the missing encryption flag at plan time.
  • The prize is shift-left for cloud posture. The same misconfiguration that CSPM finds at runtime is findable in the PR that introduces it — cheaper, and before it’s ever exposed.
  • The honest limit: IaC scanning only covers what’s in the IaC. Click-ops changes, drift, and anything provisioned outside the templates are invisible to it, which is why it complements runtime posture management rather than replacing it. The boundary is deliberate — IaC scanning is the AppSec-side tool; the posture program it feeds lives in cloud security.

This subsection is the AppSec/cloud seam by design — image and IaC scanning are AppSec practices whose findings are cloud-infrastructure risks. The API material is the defensive half of API and LLM pentesting, and it rests on the authorization and IAM fundamentals the rest of the pillar builds.

Graph View