API Security Best Practices: A Practical Guide for 2026

Securing an API comes down to a short list of habits. Encrypt every call, authenticate users with a standard protocol such as OAuth 2.0, check authorization on every endpoint, validate every input, limit request rates, and watch what happens in production. Each habit is simple to state. The hard part is applying all of them consistently across every endpoint, client and release.

This guide walks through those practices in the order a team usually meets them: design, transport, authentication, authorization, abuse controls and ongoing upkeep. It also answers the questions developers type most often next to this topic: how OAuth 2.0 and JWT fit together, what the authorization code flow does, and how to handle OAuth 2.0 in a mobile app. The guidance rests on NIST, OWASP and IETF documents, so you can check every claim at its source.

Requestum

Build APIs with security in mind

Requestum creates tailored web and mobile applications, with business analysis and QA to support high-quality software deliverables.

Explore Requestum

TL;DR

Encrypt all API traffic, including public and unauthenticated endpoints. Current NIST guidance says all runtime API communication should be protected.
Use OAuth 2.0 with the authorization code flow and PKCE for user sign-in. Treat JWT as a token format, not as a security model.
Keep access tokens short-lived and audience-restricted, keep secrets out of URLs, and rotate signing keys.
Enforce access control on every non-public endpoint on the server side, and validate every input against the API definition.
Add rate limiting, logging and regular testing, then repeat the review with every release.

Start with threat modeling, not a tool
Encrypt every call, even public ones
Authentication: what OAuth 2.0 and JWT each do
The authorization code flow, step by step
OAuth 2.0 for mobile apps
Token and API key hygiene
Access control and input validation
Rate limiting, monitoring and testing
Standards and frameworks worth adopting
A one-page API security checklist
Our perspective
Get an API built and tested with security in mind
FAQ
Sources

Start with threat modeling, not a tool

The most common API security mistake is treating protection as something added at the end. The UK's National Cyber Security Centre advises a secure by design approach, with security built into every stage of the product lifecycle. Its guidance also says threat modeling should fit the API in front of you. A public weather app and an industrial manufacturing system face different threats and carry different risks, so they deserve different controls.

In practice, a lightweight threat model before the first endpoint is written answers four questions:

Who calls this API: browsers, mobile apps, partner servers, internal services?
What is the most damaging thing a caller could read or change?
Which endpoints are public, and which require identity?
What happens if a token, key or password for this API leaks?

The answers decide how strict authentication must be, how narrow scopes should be, and where monitoring matters most. A team that cannot answer them usually discovers the gaps in production. If you want to see how this fits into a wider delivery process, our notes on a secure software development lifecycle cover where these reviews belong, and the web app security checklist turns the same ideas into controls with owners and evidence. The same thinking applies to website security and customer trust more broadly, because an exposed API is often the weakest part of the surface.

Encrypt every call, even public ones

Transport encryption is the baseline. OWASP's REST guidance says services must provide HTTPS endpoints so that credentials such as passwords, API keys and JSON Web Tokens cannot be eavesdropped in transit.

NIST goes further. Its SP 800-228 guidance specifies that all runtime API communication should be encrypted, even when the data is public or the call is unauthenticated, to protect integrity as well as confidentiality. The reasoning is straightforward: an attacker who can alter a public response in transit can still mislead your users or your own services.

What to do:

Serve every endpoint over TLS and redirect or refuse plain HTTP.
Apply the same rule to internal service-to-service traffic, not only to the public edge.
Never put passwords, tokens or API keys in URLs, because URLs end up in logs, browser history and referrer headers.
Encrypt stored data as well. Our guide to secure data storage, keys and backups covers the at-rest side.

Authentication: what OAuth 2.0 and JWT each do

Developers often search for OAuth 2.0 and JWT together because they appear together in most tutorials. They solve different problems, and mixing them up leads to weak designs.

OAuth 2.0 is about delegated access

OAuth 2.0 is an authorization framework. As Auth0 explains, it is an authorization protocol rather than an authentication protocol: it grants access to specified resources, and the access token represents permission to use those resources on the user's behalf. Under the framework in RFC 6749, a client makes requests to a resource using an access token that an authorization server issues after a grant that represents the resource owner's approval, as RFC 7523 describes it.

OAuth token grants client delegated resource access

If you need to know who the user is, add OpenID Connect on top of OAuth 2.0. NIST's API guidance recommends standard mechanisms such as OIDC, OAuth 2.0 or SAML for end-user authentication, rather than home-grown login schemes. OWASP adds that user authentication should be centralized in an identity provider, so every endpoint trusts one well-maintained component instead of many different checks. That is the idea behind the OWASP REST guidance.

JWT is one way to format the token

OAuth 2.0 does not require any particular access-token format. RFC 9068 describes JWT as a standardized option that can carry claims such as issuer, subject, audience, expiry, scopes and entitlements, so a resource server can validate authorization information itself. That is useful when the authorization server and the API are separate systems and the API should not call back for every request.

Two related points from the standards are easy to miss:

Using a JWT to authenticate a client at the token endpoint is a separate matter from using a JWT as an authorization grant. RFC 7523 says either can be used independently.
A JWT must be integrity-protected. OWASP requires a signature or MAC and warns against unsecured tokens that declare the algorithm as none. See the REST Security Cheat Sheet.

In short: OAuth 2.0 decides how a client obtains permission, and JWT is one way to write down that permission. Validate the signature, issuer, audience and expiry on every request, and reject anything that does not match.

The authorization code flow, step by step

For any application where a person signs in, the authorization code flow is the one to use. RFC 9700, the current best practice document for OAuth 2.0 security, recommends the authorization code flow, exact redirect URI matching, PKCE for public clients and audience-restricted access tokens.

The flow works like this:

The client generates a random code verifier and sends a hash of it (the code challenge) with the authorization request.
The user signs in at the authorization server and approves the requested scopes.
The server redirects back to a registered redirect URI with a short-lived authorization code.
The client sends the code and the original verifier to the token endpoint.
The server checks that the verifier matches the earlier challenge, then returns an access token, and often a refresh token.
The client calls the API with the access token.

RFC 9700 lists the safeguards that matter most. They are to prevent open redirectors, use PKCE against authorization code interception and CSRF, use transaction-bound state when PKCE is unavailable, and apply issuer-based defenses against mix-up attacks between authorization servers. Access tokens should be limited to a specific resource server or, if that is not possible, to a small set of them.

OAuth 2.0 for mobile apps

A mobile app is a public client: it cannot keep a secret, because anyone can unpack the app and read it. That is why the standard for native apps is stricter. RFC 8252 requires public native-app clients to implement PKCE and requires authorization servers to support it. PKCE ties the authorization request to the token redemption by making the client prove it holds the secret code verifier.

The same document gives a clear checklist for mobile teams:

Use the authorization code flow with PKCE, sending a hash of the verifier in the request and presenting the verifier when redeeming the code.
Sign in through an external user-agent (the system browser), not an embedded web view the app can inspect.
Register the redirect URI and match it exactly, except for the port on a loopback address.
Use a domain-based private-use URI scheme or a claimed HTTPS redirect.
Use the state parameter to guard against cross-app request forgery.
Use a distinct redirect URI for each authorization server to limit mix-up attacks.

Backend design matters as much as the client flow. If you are planning a mobile product, our mobile app backend guide covers budget and security decisions, and the mobile app testing checklist helps you verify sign-in behavior on real devices.

Token and API key hygiene

Most real incidents involve a credential that lived too long or was granted too much. The rules are consistent across the sources.

Keep tokens short-lived and narrow. OWASP notes that bearer access tokens can be used by anyone who holds them, so they should be short-lived and restricted to an audience, preferably one resource server. Refresh tokens exist to obtain a replacement when the access token expires. NIST's SP 800-228 adds that API tokens should not have long expiration times, and that credentials should be cycled and signing keys rotated regularly, per the NIST guidance.

Limit the damage from theft. OWASP's approach is to reduce the impact of a stolen token through short lifetimes, narrow audiences, careful redirect handling, PKCE and, where stronger protection is needed, sender-constrained tokens.

Do not lean on API keys alone. OWASP says not to rely exclusively on API keys for sensitive, critical or high-value resources. The U.S. Department of Defense CTO's API technical guidance goes further for sensitive data, favoring digitally signed tokens and dynamically generated keys over traditional embedded API keys.

A quick review list for any API:

No secrets in URLs, source code or mobile app bundles.
Access token lifetime measured in minutes, not days.
Audience and issuer checked on every request.
A rotation plan for signing keys that has been tested at least once.
Revocation for refresh tokens when a user signs out or a device is lost.

Access control and input validation

Authentication tells you who is calling. Authorization decides what they can do, and it must be enforced on the server for every request. OWASP's guidance is to perform access control at each non-public REST endpoint, not just at the gateway or in the user interface.

Two habits prevent most authorization bugs:

Check the object, not only the role. An authenticated user requesting an order by ID must own that order or have a role that allows access. Role checks alone miss this case.
Use scopes and claims deliberately. Scopes work well for coarse access such as read or write. Fine-grained rules, such as which account a user may touch, belong in claims or in the API's own policy logic.

Input validation is the other half. NIST SP 800-228 names runtime request validation against the API definition as a protection, alongside encryption in transit and rate limiting, in its API protection guidelines. Writing the API definition first, for example with OpenAPI, gives you a contract to validate against. Our API integration strategy describes that OpenAPI-first approach.

OWASP also recommends an allowlist of permitted HTTP methods such as GET, POST and PUT, with unmatched requests rejected using a 405 Method Not Allowed response. It is a small control that removes a surprising amount of unexpected behavior.

Rate limiting, monitoring and testing

Even a perfectly authenticated API can be abused by a caller who sends too many requests, scrapes data or probes for weaknesses. Rate limiting is one of the three protections NIST singles out, and the choice of algorithm matters. A fixed window, for example, can let a client send double the intended volume around a window boundary, as this look at API rate limiting and burst behavior shows. Sliding windows or token buckets smooth this out.

Practical settings to decide per endpoint:

A per-client limit and a lower limit for expensive or sensitive actions such as sign-in, password reset and export.
Clear 429 responses with a retry hint, so legitimate clients can back off.
Alerts on spikes in failed authentication, 403 responses and unusual object access patterns.

Logging is what turns those alerts into answers. Log who called, which endpoint, which object and what decision was made, but never log tokens, passwords or full personal data.

Testing closes the loop. The NIST publication describes pre-runtime and runtime protections and an incremental, risk-based approach, which you can read in SP 800-228. That means design reviews, automated tests and dependency checks before release, then validation and monitoring in production. If you version your API, plan deprecation carefully so security fixes do not break clients; our API versioning playbook covers that.

Standards and frameworks worth adopting

You do not need to invent a program from scratch. For U.S. teams the practical anchors are:

NIST SP 800-228 for pre-runtime and runtime API protections, in its final publication.
OWASP cheat sheets for REST and OAuth2 implementation details.
RFC 9700 and RFC 8252 for OAuth 2.0 security and native apps.
SBOM and SAMM. The U.S. CTO's technical guidance advocates a Software Bill of Materials to identify and mitigate threats, and recommends the Software Assurance Maturity Model as an open framework for improving API security overall.

For release discipline, see how we connect these ideas to security-first release management.

A one-page API security checklist

Area	What to do	Source of the guidance
Design	Threat model per API, security in every lifecycle stage	NCSC
Transport	TLS everywhere, including public endpoints	NIST SP 800-228, OWASP
Authentication	Central IdP, OAuth 2.0 or OIDC, no secrets in URLs	OWASP, NIST
Tokens	Short-lived, audience-restricted, signed, keys rotated	OWASP, NIST
Mobile	Authorization code flow with PKCE, system browser, exact redirects	RFC 8252, RFC 9700
Authorization	Server-side checks on every non-public endpoint and object	OWASP
Validation	Validate requests against the API definition, allowlist methods	NIST, OWASP
Abuse control	Rate limits, alerts, safe logging	NIST
Upkeep	SBOM, SAMM, regular testing	U.S. CTO

Our perspective

We build APIs for web and mobile products, and the pattern we see most often is not a missing tool. It is a missing owner. Someone chose an identity provider, someone else wrote the endpoints, and nobody checked that every endpoint enforced the same rules.

That is why we start API work with business analysis and a discovery phase. We map who calls the API, what data it exposes and which flows matter before a line of code is written. Security requirements then become acceptance criteria that QA can test, rather than a document that sits in a folder.

We also believe in standards over cleverness. Authorization code flow with PKCE, short-lived tokens, a central identity provider and request validation against an OpenAPI contract are not exciting, but our approach is designed around them because they hold up under audit and under attack. Our engineers and QA specialists work from the same checklist, so what is designed is what gets tested.

If your API already exists, the fastest win is usually a review of token lifetimes, scopes and object-level checks. If it does not exist yet, the cheapest moment to get security right is now.

Dmitry

Get an API built and tested with security in mind

If you are planning a new API or want an existing one reviewed, our team can help at each stage. We handle web application development, including custom web apps, CRM and ERP systems and marketplaces, and we run software testing and quality assurance so that security requirements are verified before release.

Requestum

Tell us what the API needs to do and who will call it. We will help you scope authentication, authorization and testing from the discovery phase onward.

FAQ

What are the basics of API security?

The basics are encrypting all traffic with TLS, authenticating callers through a standard protocol such as OAuth 2.0 or OpenID Connect, and enforcing authorization on every non-public endpoint. Add input validation, rate limiting and logging. These controls match what OWASP and NIST describe for REST APIs.

Should I use JWT or opaque tokens?

OAuth 2.0 does not mandate a token format. According to RFC 9068, JWT access tokens help when an API needs to validate authorization locally, especially when the authorization server is separate. Whichever you choose, keep tokens short-lived, signed where applicable and restricted to the intended audience.

Is OAuth 2.0 authentication or authorization?

OAuth 2.0 is an authorization framework: it lets a client obtain limited access to resources on a user's behalf. To learn who the user is, add OpenID Connect on top. Treat the two as separate layers in your design.

What is the safest OAuth 2.0 flow for a mobile app?

Use the authorization code flow with PKCE, sign in through the system browser and register exact redirect URIs. RFC 8252 requires PKCE for public native-app clients. Avoid embedding client secrets in the app, because they can be extracted.

Are API keys enough to protect an API?

Not for sensitive or high-value resources. OWASP advises against relying only on API keys, and U.S. CTO guidance favors signed tokens and dynamically generated keys for sensitive data. Use keys to identify callers and pair them with stronger authentication.