API security: from sound design to operational proof

APIs have become the main interface of the web: they now carry the majority of application traffic. In that landscape, the logic attack has replaced the technical exploit — badly calibrated authorisation, unlimited resource consumption, silent exfiltration. Effective defence no longer rests on an application firewall alone, but on a continuous cycle: a safe design, tests that block, and observability in production.

The real attack surface: your own API contracts

Most recent incidents come neither from a zero-day nor from an obscure framework, but from two major entries in the OWASP API Security Top 10: broken object-level authorisation and excessive data exposure.

Translated into business terms: a perfectly legitimate user can read or modify what they should not, because the resource, its identifier and its fields are not protected at the right level.

Add unbounded resources to that — no rate limiting, optional pagination — and the API turns into a quiet denial-of-service vector.

The API has become the interface to your business logic. Securing it means securing your decisions.

What works at design time

• Authentication and authorisation. OAuth2/OIDC with the Authorization Code flow and PKCE, short-lived tokens and refresh token rotation, fine-grained scopes per resource and per action.
• mTLS between services. On by default with Linkerd, automated on the Istio side by starting in permissive mode and then locking down progressively.
• Strict contracts. OpenAPI 3.1 and JSON Schema: validation of inputs and outputs, forbidden fields, bounded values.
• Explicit limits. Rate limiting, maximum body and header sizes, an idempotency key on writes. Careful: a cap per IP address is neither a cap per user nor a cap per API key.

From tests that reassure to tests that block

Shifting controls left is only worth anything if it gates the release: if the check fails, nothing ships.

• Static analysis (Semgrep, Sonar) for secrets and injections.
• Specification linting (Spectral): OWASP rules codified, breaking changes caught before the merge.
• Contract tests (Pact, Spring Cloud Contract): producer and consumer kept in step by the contract.
• Dynamic testing and fuzzing (OWASP ZAP, Burp) on ephemeral environments.
• Dedicated authorisation tests: the nominal journey, then attempts to get around it — reaching another user's object, escalating privileges.

That pipeline is only worth something if it enforces thresholds: zero critical vulnerabilities, a capped number of high ones, security coverage on at least 80% of endpoints.

At runtime, the truth of the metrics

Defence in production is not a miraculous application firewall, it is telemetry you can act on and that triggers automatic decisions.

• Gateway and WAF: adaptive rate limiting, the OWASP Core Rule Set, circuit breakers that protect the backend and degrade the service cleanly.
• Distributed traces. Every request carries its trace identifier and security attributes — user identifier, scopes, policy decision, request size. Those are what make an incident replayable.
• Structured logs and audit trail: who, what, when, from which address, correlated with the traces.
• Security-oriented metrics: rate of 401s and 403s, latency per endpoint and per user, validation errors, and behavioural alerts on spikes of refusals or identifier enumeration.

A well-tuned WAF sees an attack pattern. Application observability sees an intent.

The hygiene items, too often forgotten

• Secrets: central vault, automatic rotation, a strict ban on secrets in configuration.
• CORS and headers: explicit origins, controlled cookie handling, HSTS and CSP.
• Versioning: semantic, deprecations announced 6 to 12 months ahead and tracked in the metrics.
• Penetration testing: regularly for public APIs, with a clear scope and clear remediation deadlines.

Three decisions to take this week

1. Pin down authorisation rules at the level of the object and of its properties.
2. Make limits measurable: caps per IP, per user and per key, maximum sizes, pagination — all tested in continuous integration.
3. Enrich traces with the user identifier, the scopes and the policy decision.

Conclusion

API security is no longer a stack of tools, it is a system of evidence: a design that denies by default, tests that prevent regressions, measurements that tell you what is really happening in production. On those terms, an API stops being a blind spot and becomes an observable asset — and therefore a controllable one.

Sources

• OWASP API Security Top 10 (2023)
• OpenAPI 3.1 and JSON Schema specifications
• RFC 9700 — OAuth 2.0 Security Best Current Practice
• Istio and Linkerd documentation (mTLS)
• OWASP Core Rule Set
• OpenTelemetry — traces and attribute conventions