API security · Overview

API security: protect access, data and workflows

For every request, a secure API must decide who may read or change which data, which inputs are allowed and how much work the call may trigger. HTTPS and suitable headers are part of this. But the application determines whether a customer can retrieve another customer's invoices or a repeated job is executed twice.

Start with your concrete task: understand a finding, design access, fix an error or secure ongoing operation. This guide connects the necessary foundations with practical instructions for developers and technical operators of publicly reachable HTTP APIs. Even a publicly reachable endpoint may require authentication.

Find a relevant article Open API Security Check

First establish what the API may trust, and from whom

An API is an interface through which programs exchange data and trigger functions. In HTTP, this includes an address, a method such as GET or POST, request headers and possibly content. The response contains a status, headers and potentially data. An endpoint here means a specific reachable API address; the same address may serve different purposes depending on the method.

The first security question is: which information comes from outside, and which decisions may it influence? A customer ID sent by the browser is initially only a claim. A valid token may establish identity without granting that identity access to every record. A signed partner message may be authentic yet arrive twice or late.

Sketch the stages of an important flow: client, gateway or reverse proxy, application, database, background job and external service. Mark where data or identities cross areas of responsibility. That is a trust boundary: the receiving side must decide what it checks itself and which narrow assurance it relies on. This is an entry point into threat modelling, the systematic identification and treatment of potential failure and abuse cases.

A synthetic example: a team may request an export through its API. The application must verify team access, select permitted data, limit work and concurrency, and pass the correct team context to the background job. The later download needs another appropriate access decision. One check at the first form does not solve this chain.

Synthetic example · not a check result

Team export: carry access and context through the chain

A member of Team Blue requests an export. The output may contain only the records that Team Blue is permitted to access.

Client → API: check team access
The supplied team ID is initially only a claim. The application decides whether the caller has access to that team.
API → request: limit data and workload
The application selects the permitted team data and limits the export workload and concurrency.
Request → background job: preserve team context
The handover must carry the correct team context. The job processes the permitted team data assigned to the request.
Background job → download: decide access again
The export remains assigned to its team. At download time, the application again decides whether this caller may receive this export.

A check at the initial form does not cover later transitions. Team context, permitted data and the allowed action must be checked at every relevant trust boundary.

Find the right guide for your task

You need not read the series in order. For a new API, the sequence follows a request's path and later operation. For a specific error, go directly to the affected task.

On narrow screens, scroll the table sideways.

Find the right guide for your task
Your task	Starting point and further reading
Choose access for browsers, services or third-party applications	Choose authentication, then API keys or OAuth and OIDC; for API-side token checks, validate JWTs.
Prevent access to others' data and forbidden actions	Object access: BOLA and IDOR, roles and function permissions, field permissions and mass assignment, and, for multiple organisations, tenant isolation.
Process requests cleanly and respond clearly	Validate input, errors and status codes, and interpret HTTP findings correctly.
Use an API from the browser	Configure CORS, investigate CORS errors and cookies and CSRF. Specific implementations: nginx and Express.
Limit costs, load and unwanted business flows	Rate limits and resource budgets, retries and idempotency, secure business logic.
Exchange data and events with other services	Prevent SSRF through target URLs, process external API responses securely and verify and process webhooks.
Manage architecture and ongoing operation	Gateway responsibilities, inventory and versioning, logging, monitoring and response.
Use GraphQL and its particular execution capabilities	Secure GraphQL: resolver and field permissions, query costs and error behaviour.
Test reliably after a change	Test your own API security connects expected behaviour, your own test data and meaningful negative cases.

For transport and shared browser foundations, use the existing guides to TLS certificates, HSTS, Cache-Control and cross-origin headers. They complement application controls; none of these measures replaces the others.

Which kind of evidence answers your question?

Authentication verifies an identity or credential. Authorisation decides what this caller may do in the current context. Business rules additionally determine which action is still permitted in a flow at all. This distinction helps select the appropriate test.

On narrow screens, scroll the table sideways.

Which kind of evidence answers your question?
Question	Suitable evidence	What does not follow yet
Which headers does this endpoint return?	Response to a specified request with time and context.	Other paths, methods, signed-in users or later responses look the same.
Can another organisation read this record?	Your own test identities, known example data, expected permissions and actual data/state comparison.	A single denied retrieval proves every list, export and background job.
Does a job take effect only once despite retries?	Controlled repetition and concurrency in an isolated environment; stored state and triggered follow-up work.	A successful HTTP status proves the business effect.
Will an abuse attempt be noticed?	A defined test event, visible signal and traceable handling path in your operations.	An existing log entry is also monitored or leads to a response.

The OWASP API Security Top 10, 2023 edition, helps identify major risk groups, including identities, permissions, resources, business flows, external services and outdated API inventories. It is neither a complete testing guide nor a legal standard. Choose controls from your data, flows and possible harm; checking off ten headings is insufficient.

When the browser cannot read a response

CORS governs whether browser code may use a response from another origin. An origin consists of scheme, host and port. A browser error does not automatically mean the server received no request or performed no action. Some requests have an OPTIONS preflight first; others are sent before the browser withholds their response.

First check the actual calling origin, credentials mode, preflight response and actual response. CORS is neither authentication nor server-side authorisation. Even suitable CORS permission says nothing about object or tenant rights. CORS diagnosis distinguishes these cases; cookies and CSRF covers protection against unwanted actions. The Fetch Standard provides the technical basis.

Consider the actual response type. JSON, a file download and an HTML login page before an API need different assessments. Content-Type should match delivered content. Cache rules must distinguish generally public from user-specific data. An advertised DELETE does not prove unauthorised callers can delete.

A product version named in a header is also initially a self-report from one involved layer. Establish whether a known security issue actually applies using installed package version, vendor notices and configuration. The HTTP findings guide explains the path from signal to suitable verification. It leads to existing web foundations without treating every JSON API like an HTML page.

When errors, delays or duplicate operations occur

A stack trace in a response is a concrete reason to correct the error path. An unremarkable response does not cover every error path, however. For 401, 403 or HTML instead of JSON, status codes and safe error responses helps locate the cause in the correct part of the chain.

429 Too Many Requests reports a limit; a present or absent limit header proves neither comprehensive protection nor its absence. For the operator's decision, read rate limits. Before a client retries after a timeout, establish the uncertain outcome and idempotency of the operation. Otherwise, a well-intended retry may trigger extra work or a duplicate action.

Turn an open question into a verifiable next step

For a finding, record URL, method, time, expected function and authentication state. Browser problems also need origin and credentials context. Remove keys, tokens and confidential content from material you share. Then formulate a testable expectation, such as: ‘A Blue team member sees only records approved for Blue in the export.’

For selected public response characteristics of an endpoint you own or are explicitly authorised to test, the API Security Check can provide a limited initial finding. Read the scope before starting. It sends defined GET/OPTIONS requests and a limited GET error probe. It tests neither signed-in roles nor object permissions, business logic or actual rate-limit enforcement. A good grade does not grant security approval; an unmeasured part does not count as passed.

A report documents the existing measurement and does not extend testing. Assess changes using suitable new evidence; a download is no new measurement. For application controls, testing your own API security provides a development and testing path.

A scanner API, by contrast, would provide programmatic access through which other software starts Wolf-Agents checks or retrieves results. Such access is not offered here. The check overview distinguishes the available web, email and API testing paths.

Sources and context

This guidance draws on the OWASP API Security Top 10 2023, OWASP Threat Modeling, HTTP semantics in RFC 9110 and the Fetch Standard. Sources checked: 27 September 2026. Linked technical articles name further sources and example limitations. This guide is not a test result for your application.

Service status