Securing your APIs: best practices, from OAuth 2.1 to AI agents

APIs, the primary attack surface of distributed systems

APIs sit at the heart of modern architectures, microservices, mobile applications, partner ecosystems, which makes them the attackers' favourite target. Recent figures leave no doubt: 87% of organisations report having suffered an API-related security incident in 2025 according to Akamai's State of the Internet report, and the average number of daily attacks per organisation more than doubled in a year.

The threat reference remains the OWASP API Security Top 10, whose 2023 edition is still authoritative: broken object level authorization (BOLA), broken authentication and misconfigurations account for most of the exploitation observed. In other words, attackers do not break cryptography, they exploit incomplete authorisation logic and forgotten APIs.

The pressure keeps rising with AI: API vulnerabilities tied to artificial intelligence integrations were multiplied by nearly five in one year according to the 2026 API ThreatStats report, driven by the proliferation of endpoints exposing models and agentic tools. Every new AI interface is one more API to inventory, authenticate and monitor, often deployed faster than security processes can follow.

Securing your APIs is therefore no longer a peripheral project: it is a pillar of the overall security posture. Five fronts structure a solid defence in 2026: authorisation, token resistance to theft, traffic control, lifecycle governance and, now, AI-driven consumers.

OAuth 2.1 and PKCE: state-of-the-art authorisation

OAuth 2.1 is the de facto authorisation standard: this revision, in its final phase at the IETF, consolidates into a single text fifteen years of best practices accumulated since OAuth 2.0, notably incorporating RFC 9700 (Security Best Current Practice, published in January 2025). The major authorisation servers already implement it: there is no reason to wait for the formal RFC publication to comply.

The flows to use: and the ones to ban

PKCE (Proof Key for Code Exchange) becomes mandatory for all client types, including confidential ones. Three flows cover legitimate needs: the authorisation code flow with PKCE for browser-based applications, the device flow for browserless clients, and client credentials for server-to-server exchanges. The implicit flow and the resource owner password flow are formally removed: their presence in an API in 2026 is a red flag in itself.

Redirects and CSRF protection

A few rules complete this foundation: redirect URIs over HTTPS, absolute and compared by exact match against the registered ones; the "state" parameter alongside PKCE against cross-site request forgery; and a single authorisation server to centralise signing key management rather than scattering trust.

Authorisation does not stop at obtaining the token: most of the exploitation observed falls under object-level access control. Every handler must verify that the calling identity is entitled to the specific resource requested, never infer that right from the mere fact that the request is authenticated. OAuth scopes delimit families of actions; the fine-grained decision is made on the application side, ideally centralised in a testable policy engine rather than scattered across every endpoint.

Theft-resistant tokens: DPoP, mTLS and JWTs used well

OAuth's historic weak link is the bearer token: whoever holds it can use it. The modern answer is the sender-constrained token: with DPoP (RFC 9449), the client proves on every request that it holds the private key associated with the token; with mTLS (RFC 8705), the token is bound to the connection's client certificate. In both cases, an exfiltrated token becomes unusable by the attacker, a paradigm shift for sensitive APIs.

JWTs: the rules that do not change

The fundamentals remain valid: opaque tokens for exchanges with third parties, JSON Web Tokens reserved for internal use; systematic short expiration, with refresh token rotation to detect reuse; a strict allowlist of accepted signing algorithms; and never any sensitive data in a JWT payload, readable in plaintext by anyone who intercepts it. Revocation must also be tooled: a compromised token must be invalidated in minutes, not hours.

Secrets management completes this pillar: signing keys stored in a dedicated manager or an HSM, automatic and scheduled rotation, an absolute ban on hardcoded secrets in code or client configurations. Recent incidents are a reminder: the leak of an API key in a public repository remains one of the most common attack paths, and one of the most avoidable. Transport, finally, remains the baseline: TLS 1.3 everywhere, including between internal services, as east-west traffic has become as important a target as exposed traffic.

Rate limiting and business logic abuse detection

Rate limiting bounds the number of calls to the API over a given period. It prevents denial-of-service attacks, slows credential stuffing and mass scraping, and protects the reliability of the service by stopping a client, malicious or not, from saturating shared resources.

Choosing your limiting algorithm

Several algorithms coexist: the leaky bucket smooths traffic in a first-in, first-out queue; the fixed window is simple but vulnerable to bursts at window edges; the sliding window neutralises these edge effects; the token bucket, finally, allows controlled spikes while bounding the average rate. What matters most is applying limits per authenticated identity, client, user, agent, rather than per IP address, which is easily bypassed.

Rate limiting alone is no longer enough, though: attacks that respect quotas but abuse business logic, identifier enumeration, hijacked purchase journeys, require behavioural detection at the gateway or WAAP, crossing traffic signals with application context.

GraphQL APIs deserve specific treatment: a single request can trigger considerable load through field nesting. Limiting query depth and complexity, capping the computed cost of each call and disabling introspection in production are part of the minimum baseline for this style of API.

Related readDevSecOps: 10 best practices for building security in from the startTen DevSecOps best practices to build security into your CI/CD pipeline: SAST, DAST, software supply chain, hardened containers and a shared culture in 2026.Read the article

Governance: inventory, API contract and security in CI/CD

You cannot protect what you do not know: shadow APIs, deployed outside official processes, and zombie APIs, old versions never decommissioned, rank among the leading causes of incidents. A continuous inventory, fed by automatic discovery from real traffic, is the prerequisite of any API security strategy.

The OpenAPI contract as a control point

Each API's OpenAPI specification becomes a control point: security linting in CI to catch overly permissive schemas, request and response validation at the gateway to reject anything outside the contract, dynamic security tests replayed on every deployment. The gateway centralises authentication, authorisation and telemetry, so that each team does not have to reinvent these critical building blocks.

Governance finally covers the whole lifecycle: explicit versioning, a deprecation policy communicated to consumers and effective decommissioning of old versions, measured, not merely announced. An API removed from the developer portal but still reachable in production remains an entry point for an attacker, made worse by the fact that it is no longer monitored or patched.

This tooled hygiene is complemented by adversarial verification: penetration tests targeted at the most critical APIs, fuzzing campaigns on inputs to flush out the edge cases that functional tests ignore, and responsible disclosure programmes that channel the findings of external researchers. The goal is to regularly confront the setup with real attack conditions rather than rely on automated controls alone, attackers, for their part, do not restrict themselves to the perimeter declared in the contract.

Related readAPI Design: REST vs GraphQL and BeyondREST, GraphQL, gRPC: what each API style demands of client and server, and how to choose on your use case rather than on fashion.Read the article

Securing APIs in the age of AI agents and the MCP protocol

A new category of consumers has emerged: AI agents, which call the company's APIs autonomously, often through the MCP (Model Context Protocol). Around half of developers cite unauthorised API calls by agents and credential leakage tied to AI integrations among their top concerns, rightly so: an over-privileged agent can chain in seconds actions no human user would have performed.

The countermeasures exist and echo the fundamentals: a dedicated machine identity per agent, never shared human credentials; narrow scopes and short-lived tokens, aligned with the task at hand; human approval for irreversible actions; and systematic logging that distinguishes agentic traffic from human traffic for audit and anomaly detection. Finally, rate limits specific to agentic traffic, stricter than those for human users, contain the impact of an agent running out of control.

The MCP protocol itself is converging on these standards: its authorisation specification builds on OAuth 2.1, which makes it possible to apply to MCP servers the same requirements as to any API, client registration, explicit scopes, short-lived tokens. Treating an MCP server as a full-fledged API, subject to the same controls and the same inventory, is the safest position.

Related readAI agents shouldn't be a security nightmarePrompt injection, data exfiltration, rogue agents: a six-layer framework to deploy AI agents safely in production, from least privilege to the kill switch.Read the article

The Adservio approach: API security designed upstream

At Adservio, we treat API security as a coherent whole rather than a sum of one-off fixes: modern authorisation, theft-resistant tokens, traffic control, lifecycle governance and supervision of AI consumers form a foundation thought through from the design stage, in a DevSecOps logic.

Our conviction: a well-protected API is one whose security was designed upstream, not bolted on afterwards. We support your teams in putting these practices in place, from the initial audit to CI/CD tooling, and transfer control to them so they can sustainably maintain a high level of security.

This approach relies on measurable milestones: inventory coverage, share of APIs compliant with OAuth 2.1, revocation latency for a compromised token, time to detect abnormal behaviour. API security is steered like reliability: through indicators tracked over time, not through one-off audits.