API Security Architecture

API security incidents in enterprise estates tend to share a structure. A single layer — usually authentication or authorisation — was defending the whole surface. When that layer was bypassed, partially compromised, or misconfigured, there was no second line to catch the failure. The incident becomes the company's problem because there was no defence in depth.

This piece is the layered architecture we recommend, with each layer treated as an independent concern with its own threat model, its own controls, and its own audit posture.

Layer 1 — Network position and the gateway

The first defensive layer is network position. API gateways are the place where external traffic terminates and internal traffic begins. The gateway is the right place to enforce IP allowlists for partner traffic, the right place to apply rate limits, the right place to drop traffic at the perimeter before it ever reaches application code.

The gateway should also be the only place where external traffic can reach the integration platform. Estates that allow direct connectivity to internal services in addition to gateway routing have lost the architectural benefit of the gateway; the gateway becomes a recommendation, not a control.

Controls at this layer:

• IP allowlisting per consumer for partner-grade integrations
• Rate limiting per consumer, per API, per endpoint
• DDoS protection upstream of the gateway (cloud DDoS services, CDN, WAF)
• TLS termination with strict cipher policy
• Direct internal access disabled — every external request goes through the gateway

The estates that handle this layer well usually run their API gateways behind a CDN with WAF protection (Cloudflare, Akamai, AWS Shield, Azure Front Door). The estates that handle it poorly have gateways exposed directly to the public internet with no upstream protection.

Layer 2 — Transport security

The second layer is transport security. Even after the perimeter has accepted the connection, the transport layer must ensure that the conversation is private and that the parties are who they claim to be.

For partner traffic and high-sensitivity APIs, mTLS is the right default — both ends present certificates, both verify the other. The trust relationship is explicit and certificate-based.

For internal service-to-service traffic, service mesh mTLS (Istio, Linkerd, AWS App Mesh) provides the same protection without the operational burden of manual certificate management.

For consumer-grade public APIs, TLS 1.2 minimum (preferably TLS 1.3) with strict cipher policy, regular certificate rotation, and OCSP stapling.

Controls at this layer:

• TLS configuration audited and locked to current best practice
• Certificate lifecycle managed automatically (ACME, mesh CAs)
• Plaintext HTTP rejected at the gateway, not silently upgraded
• Internal traffic protected at the same standard as external — defence in depth assumes the perimeter could be bypassed

We have audited estates where internal API traffic was plaintext on the assumption that the network was trusted. That assumption is increasingly untenable; lateral movement after a breach exploits exactly this confidence.

Layer 3 — Authentication

The third layer is authentication — proving who the caller is. The default for service-to-service traffic is OAuth 2.0 with the client credentials grant. The default for user-context traffic is OAuth 2.0 with authorisation code + PKCE. The default for partner federated traffic is JWT bearer with verified signature against the partner's published JWKS.

Mistakes that recur:

• Accepting JWTs without verifying the signature
• Accepting tokens past their expiry because the validation was loose
• Using shared bearer tokens across multiple consumers (cannot revoke individually, cannot attribute)
• Long-lived tokens stored in client configuration (compromise has unbounded lifetime)
• Default service accounts with broad scopes used for every integration

Controls at this layer:

• Every gateway endpoint enforces authentication
• JWT validation includes signature, issuer, audience, expiry, and algorithm allowlisting
• Tokens are short-lived (minutes to hours)
• Each consumer has its own credentials; revocation is per-consumer
• Service accounts are scoped to the minimum operation set

Authentication is the single layer that gets the most attention and is still the most commonly compromised. Most authentication breaches result from misconfiguration, not from cryptographic weakness.

Layer 4 — Authorisation

Authentication tells you who the caller is. Authorisation tells you what they are allowed to do. The two are not the same and treating them as the same is one of the more common architectural mistakes.

Authorisation models in widespread use:

Role-based access control (RBAC). The caller's role determines the operations allowed. Simple, well-understood, works for most enterprise APIs.

Attribute-based access control (ABAC). Authorisation decisions consider attributes of the caller, the resource, and the context (time, location, sensitivity). More expressive; more complex to implement consistently.

Policy-based access control. Authorisation is expressed as policy code (Open Policy Agent, AWS Cedar). The policy engine evaluates each request. Most expressive; requires governance discipline.

For most enterprise APIs, RBAC with some attribute-based extensions (resource ownership, business unit boundaries) is the sweet spot. Pure ABAC is justified for high-sensitivity, multi-tenant, or government estates.

Mistakes that recur:

• "Authenticated == authorised" — once the caller is known, any operation is allowed
• Authorisation logic scattered across endpoints rather than centralised
• Role assignments that drift from the organisational reality
• Resource-level authorisation that allows cross-tenant data access by ID enumeration

Controls at this layer:

• Authorisation decisions are auditable — every denied request is logged with the policy that denied it
• Authorisation is enforced at the resource level, not just the endpoint level
• Resource access is scoped to ownership, not to URL knowledge
• Role assignments are reviewed periodically against current organisational reality

The classic OWASP API Top 10 failure mode — Broken Object Level Authorization — is an authorisation layer failure. The caller is authenticated; the URL accepts an ID; the response returns data for any ID the URL specifies. Defence against this requires explicit resource-level authorisation in every endpoint that takes an identifier.

Layer 5 — Input handling

Authenticated, authorised callers can still send malicious or malformed input. The fifth layer is what happens to the request body, query parameters, and headers after authentication and authorisation have passed.

Controls at this layer:

• Schema validation at the API boundary — rejecting requests that do not match the published OpenAPI spec
• Size limits — bodies cannot exceed configured size; this is the simplest defence against payload-based denial of service
• Content-type enforcement — requests must match the content types the endpoint accepts
• Injection-aware downstream calls — parameterised queries, escaped templates, no string concatenation of untrusted input into commands or queries
• Output encoding — responses are encoded for their consumption context (HTML escape for browsers, JSON for JSON consumers); avoids reflection-based exploits

Input handling is the layer where SQL injection, command injection, SSRF, XXE, and a long list of classical web vulnerabilities are defended. The vulnerabilities are well-understood; the failures occur where the controls are missing in some endpoints rather than across the whole estate.

Layer 6 — Audit and detection

The final layer is the assumption that something will fail and the desire to know about it. Audit and detection at the API layer captures:

• Every authentication attempt, successful or failed
• Every authorisation decision, especially denials
• Every request that violated input constraints
• Every consumer's usage pattern, with anomaly detection on sudden changes
• Every administrative action against the API platform itself (policy changes, credential issuance, role changes)

This audit is the input to security monitoring. The estates that detect breaches early are the ones where audit feeds a security information and event management (SIEM) pipeline with detection rules tuned to API-specific signals.

The estates that detect breaches late, or do not detect them at all, are usually estates where the audit was implemented but never wired into detection.

What gets missed

Across the audits we have run, the controls most commonly missing or weak:

• Resource-level authorisation (the OWASP API1:2019 BOLA category continues to be the most common API vulnerability)
• JWT validation that actually validates (signature verification is often missing or trivially bypassed)
• Internal API traffic with weaker controls than external (defence in depth assumes the perimeter could be bypassed)
• Rate limiting that scales the wrong dimension (per-IP rate limiting when the real abuse is per-account)
• Audit that exists but does not feed detection

These are not exotic. They are the bread-and-butter controls that get deferred during delivery and are still deferred years later.

What to do today

If you are responsible for API security in an enterprise estate:

1. Run an inventory: every API in production, what authentication, what authorisation, what input controls
2. Find the resource-level authorisation gaps. They are present. Closing them is the highest-leverage security work available.
3. Verify that JWT validation actually validates. Test with an unsigned JWT; test with a JWT signed by a different issuer; test with an expired JWT. Most estates have at least one endpoint that accepts at least one of these.
4. Bring internal API traffic up to the same control standard as external. The "trusted network" assumption needs to be retired.
5. Wire the audit layer into your SIEM or equivalent. Audit that nobody reads is audit that does not exist.

API security is not a single product or a single layer. It is a discipline applied across six layers, each with its own controls and its own audit. The estates that hold up under attack are the ones where every layer is doing its job. The estates that are breached are usually the ones where one layer was treated as sufficient.