Web API Security Best Practices

To secure a web API, authenticate callers, authorize every requested action against the specific object and fields involved, validate inputs and integrated data, constrain resource use and outbound requests, and keep production configuration and API inventory under control. Build these checks into design, implementation, testing, and release reviews. The OWASP API Security Top 10 2023 is a useful API-specific checklist, not a complete security standard or a measured ranking of the most prevalent flaws.

Start with a repeatable security review

Use a checklist that follows the API’s threat model. For every endpoint, identify who can call it, what objects and properties it exposes, what work it triggers, what services it calls, and which deployed versions serve it. Review the answers during design and again when endpoints, permissions, integrations, or business processes change.

Map assets and trust boundaries. Identify sensitive data, privileged operations, credentials, dependent services, and public entry points.
Define access rules. Specify which identities may perform which actions on which objects and fields.
Set resource and business safeguards. Bound expensive operations and identify flows that could be abused through automation.
Constrain external interactions. Validate remote addresses and treat data returned by third-party APIs as untrusted input.
Review configuration and inventory. Check production settings, hosts, deployed versions, and documentation for drift and forgotten surfaces.
Repeat checks in the delivery process. Use security requirements and tests that match the system rather than assuming one tool covers every risk.

Apply the OWASP API Security Top 10 as a checklist

The 2023 edition names ten API-specific risk categories. Turn each into a concrete review question. OWASP describes the list as an awareness document: its public data call did not produce data suitable for statistical analysis of the most common API issues, so do not treat its order as a measured prevalence ranking. Generic application risks such as injection and vulnerable components also remain in scope. See the OWASP API Security Top 10 and its methodology and data notes.

Risk	Review question	Practical control
API1: Broken Object Level Authorization	For each object ID in a request, may this caller access that exact object?	Check ownership, tenancy, or other access policy on every object operation. Never rely on an unguessable identifier as authorization.
API2: Broken Authentication	Can identity or token flows be forged, misused, leaked, or accepted after they should expire?	Use a well-understood identity flow, protect credentials in transit and storage, and validate tokens and their intended use.
API3: Broken Object Property Level Authorization	Can the caller read or modify fields they should not access?	Allowlist input fields and response properties for each operation. Avoid automatically binding arbitrary request fields to internal models.
API4: Unrestricted Resource Consumption	Can a caller consume excessive compute, storage, bandwidth, or paid downstream resources?	Bound request sizes and expensive work; apply limits and safeguards appropriate to the operation.
API5: Broken Function Level Authorization	May this identity invoke this function, especially privileged or administrative operations?	Enforce role and policy checks on the operation itself, not just on a route grouping or user interface.
API6: Unrestricted Access to Sensitive Business Flows	Could valid requests automate or distort a sensitive process such as purchases or posting?	Identify business-flow abuse and add safeguards suited to the workflow, beyond ordinary login checks.
API7: Server Side Request Forgery	Can user-controlled input make the server fetch an unintended remote resource?	Validate and constrain destinations for outbound requests, including redirects and resolved addresses where relevant to the design.
API8: Security Misconfiguration	Are production services, debug surfaces, and deployment settings configured safely?	Review defaults and exposed surfaces, remove development-only behavior, and maintain secure configuration across environments.
API9: Improper Inventory Management	Do you know every deployed API host and version, including old or undocumented ones?	Maintain an inventory and lifecycle plan; remove or secure versions that should no longer be reachable.
API10: Unsafe Consumption of APIs	Are responses from integrated services treated as trustworthy without validation?	Validate data returned by third-party APIs and handle unexpected content safely.

Separate authentication from authorization

Authentication establishes who or what is calling. Authorization decides what that identity may do. A valid token does not grant permission to every object, field, or function that the caller can name.

Check authorization at object, function, and property level

Object: On every read, update, and delete, check access to the specific record in the request. Include tenant boundaries and relationships in the policy.
Function: Check permission for the requested operation, including administrative or state-changing actions. Hiding a button or route in a client is not an enforcement point.
Property: Define which input fields can change and which output fields can be returned for each caller and operation. Reject or ignore unapproved fields according to a consistent documented policy.

Review authorization across alternate paths to the same data: collection and detail endpoints, bulk operations, exports, nested resources, and background jobs. Tests should vary identity, object ownership, role, and requested fields so they exercise policy boundaries.

Protect identity and OAuth flows

Choose an identity flow appropriate to the client and validate the tokens it receives. OAuth 2.0 is an authorization framework; OpenID Connect adds an identity layer that lets a client verify an end-user identity based on authentication by an authorization server.

When OAuth authorization code flow is in scope, OWASP recommends Authorization Code with PKCE, including for single-page and native applications, and marks the implicit grant deprecated. Bind protections to the authorization transaction. PKCE protects authorization codes; it does not by itself protect access or refresh tokens. Consider additional token protections, such as sender-constrained tokens where supported and warranted. Consult the living OWASP OAuth 2.0 Protocol Cheat Sheet for current guidance.

Constrain resource use and business-flow abuse

Abuse does not have to involve a stolen identity. A caller with valid credentials may still trigger expensive work or automate a sensitive business process. Review both technical resource exhaustion and misuse of valid workflows.

Identify operations with high compute, large responses, storage effects, or paid downstream calls.
Set limits and safeguards that fit the operation and user experience; consider request size and the amount of work a request can initiate.
Examine sensitive flows such as purchases, posting, account changes, or other actions where automation can cause harm.
Check that bulk and asynchronous paths receive controls too; moving work to a job queue does not remove the underlying resource or authorization risk.

The right thresholds depend on the service and threat model. The OWASP categories identify what to examine, not a universal rate limit or configuration value.

Secure outbound requests, configuration, and integrations

Reduce SSRF exposure

If an API fetches a URL or otherwise connects to a user-influenced destination, treat that input as a boundary crossing. Validate and constrain permitted destinations to the service’s intended use. Account for redirects and address resolution in the design, and avoid allowing user input to select arbitrary internal or sensitive targets.

Keep production configuration deliberate

Review deployed settings and exposed debug or development surfaces. Verify that services use configuration intended for production and that changes do not silently expose administrative or diagnostic behavior. Apply the same review when adding a new host, integration, or deployment environment.

Inventory APIs and validate provider data

Keep a current list of API hosts and versions, including internal and older deployments. Assign ownership and a lifecycle state to each. For third-party integrations, validate returned data before using it in sensitive decisions, rendering, or downstream requests; a provider response is still external input.

Build security checks into development and release

Write security requirements for identity, object and field access, resource use, external requests, and version lifecycle.
Review endpoint changes for new data exposure, elevated functions, expensive work, and new integrations.
Test authorization with callers who should be denied as well as those who should succeed.
Include generic application security work alongside API-specific review. The API Top 10 does not replace broader secure development practices.
Repeat checks consistently in the team’s design, implementation, and release process, then update them as the threat model changes.

OWASP’s developer next steps point to security requirements and architecture resources, including the REST Security Cheat Sheet, as well as intentionally vulnerable applications such as crAPI and Juice Shop for hands-on learning.

Or skip the browser setup

For security documentation, dashboards, or review evidence that needs a page capture, ScreenshotNeo provides a website screenshot API and MCP server. Here is a one-call capture; see the ScreenshotNeo API documentation for options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month, no card required.

Troubleshooting API security reviews

Symptom	Likely cause	What to check
A signed-in user can see another user’s record	Authentication was checked, but access to the specific object was not.	Trace the object lookup and ensure authorization uses the requested record and caller context on every access path.
A caller can set a privileged field in an update	Request properties are accepted too broadly or bound directly to an internal model.	Use an operation-specific field allowlist and test fields the caller must not change.
A low-privilege identity can invoke an administrative action	Authorization is applied at a broad route or interface level, not to the function.	Enforce and test permissions at the operation boundary.
Usage costs or service load rise sharply	Expensive work, large inputs, bulk paths, or downstream calls lack suitable limits.	Map resource-heavy operations and apply safeguards to synchronous, bulk, and asynchronous paths.
A URL-fetching feature reaches an unintended destination	User-controlled remote addresses are not constrained, or redirects and resolution are not considered.	Constrain destinations to the feature’s need and review redirect and address handling.
A retired endpoint remains reachable	Host and version inventory is incomplete or has no ownership and lifecycle process.	Reconcile deployed services with the inventory and remove or secure obsolete versions.
Unexpected provider data affects application behavior	Integrated API responses are trusted without validation.	Validate the fields and formats consumed by the application and handle invalid data safely.

Performance, reliability, and cost considerations

Security controls should be designed with the operation they protect. Authorization checks need to cover every relevant object and action; resource safeguards should focus on expensive work and sensitive flows. External dependencies introduce their own failure and trust boundaries, so validate their data and constrain what the service asks them to do. Keep the controls repeatable in review and release processes so that new endpoints and versions do not bypass them.

There is no single safe threshold or control set for every API. OWASP advises teams to define requirements and use a repeatable process suited to project needs. Its API-specific categories sit alongside general application security work, not in place of it.

FAQ

Is the OWASP API Security Top 10 a security standard?

No. It is an awareness framework of API-specific risk categories. Use it with broader application security requirements and a threat model.

Does HTTPS make an API secure?

Transport protection does not decide which authenticated callers may access a particular object, function, or field. Review authorization and the other risks alongside transport security.

Does PKCE protect every OAuth token?

No. PKCE protects the authorization code flow against code interception. Access and refresh token protections require additional consideration.

Should every API use the same limits?

No. Choose resource and business-flow safeguards based on the operation, system costs, and threat model.

Does the API Top 10 cover injection and vulnerable dependencies?

It focuses on risks specific to APIs. Generic application risks such as injection and vulnerable components still need attention.