What Is API Security Testing

What is API security testing?

API security testing checks whether an application programming interface protects data and business operations from misuse. It examines who can call the API, which records and actions they can access, how requests are handled and what happens when controls fail.

A functional test may confirm that an order can be created. A security test asks whether the wrong customer can read that order, change its price or trigger the operation repeatedly.

What does an API security test cover?

Start with the service’s business purpose and trust boundaries. Include the endpoints used by websites, mobile apps, partners and internal services, along with older versions still reachable. Agree which environments, accounts and integrations are authorised for testing.

Authentication

Authentication checks who is calling the API. Verify credentials or tokens before granting access, including whether a token intended for one service is incorrectly accepted by another. Never treat possession of any valid token as permission for every operation.

Check encryption in transit and whether credentials or tokens leak into URLs, logs or error messages. Token-based authentication still needs server-side access decisions on each relevant operation.

Make authentication checks specific to the design. Where password login exists, use agreed test accounts to check rejection of common or compromised passwords and protection against repeated guesses. Confirm recovery and multi-factor authentication cannot be bypassed through an alternative login path. See OWASP authentication guidance.

Where OAuth is used, it governs delegated authorisation; OpenID Connect adds an identity layer. Check permitted redirect destinations, protection of the authorisation-code exchange, token audiences and allowed operations. The API must still enforce record and tenant permissions. For example, a read-only token should not authorise changing an order. Use the OWASP OAuth guidance to scope checks appropriate to the deployed flow.

Authorisation: object, property and function permissions

Authorisation checks what each caller is allowed to do: access individual records (objects), read or change fields (properties), and use privileged operations (functions). Cover both different users with similar roles and users with different privileges. For a multi-tenant service, verify the organisation boundary as well as the individual account boundary.

A tenant is a separate customer organisation or workspace within a shared service. A user who belongs to one tenant must not gain another tenant’s access simply by changing a record identifier.

Data validation

Check that requests contain only permitted fields, types and values, with appropriate size and range limits. Enforce these checks on the server and verify that rejected input cannot cause an unintended change. See the detailed validation and injection checks below for practical examples.

Sessions

Check how session identifiers and tokens are issued, validated, expired and revoked. Test what happens after sign-out, account recovery and privilege changes, including whether previously issued credentials still allow access they should no longer provide.

For opaque session identifiers, review how securely they are generated and whether they can be predicted; a token that looks random is not sufficient evidence. Signed tokens such as JWTs require verification of their cryptographic integrity, trusted issuer, intended audience and validity period. Readable claims are not by themselves a flaw. See OWASP's session-management and JWT guidance.

Business flows, limits and integrations

Beyond the four areas in the diagram, review sensitive operations such as bookings, approvals, purchases and exports. Agree safe limits for testing resource use, automation and repeated requests. Also examine configuration, endpoint ownership and how the API trusts data received from other services.

Does the approach differ for REST, GraphQL and other APIs?

The access-control and business-risk questions remain, but the test methods must suit the technology. REST reviews cover routes, methods and resource permissions. GraphQL reviews also need field and resolver permissions, query depth and cost limits, and batching behaviour. SOAP and other interfaces need checks appropriate to their messages, parsers and security configuration. A single URL is not necessarily a small scope.

See the OWASP REST guidance and GraphQL guidance. Include the technologies actually deployed rather than applying an identical scanner configuration to every interface.

Example: two customers and one API

In an authorised test environment, Customer A and Customer B each have an order. A request made using A’s session should return A’s permitted order, while a request for B’s order must be rejected without exposing B’s data. The server must make this decision even if the user interface hides the other order.

Repeat the check for updating a record, viewing restricted fields, exporting data and calling administrative functions. A denied read does not establish that every write or export route is protected. Use synthetic test records rather than real customers’ data.

Which API risks should be considered?

The OWASP API Security Top 10 (2023) is a useful risk reference, not a complete test plan. Its categories can be grouped into the following review areas.

Also test the application’s particular data-validation and business rules. For example, a price or approval status supplied by a client must not automatically be trusted because it passes a schema check.

Input validation and injection: what should be checked?

Validation checks that a request has the expected structure and makes sense for the operation. Review required and unexpected fields, types, lengths, ranges, nested objects and request-size limits. Check business relationships too: a delivery date must be valid for the order, and an amount must be appropriate to the permitted transaction. Apply the checks on the server; a form or mobile app can be bypassed.

Validation is only part of the defence. Keep database commands separate from data through parameterised queries. Where API data is displayed in a browser, use safe rendering and output encoding appropriate to that destination. Returning an unexpected string in JSON does not, by itself, establish cross-site scripting; examine how the consuming application uses it. See OWASP input validation, SQL injection prevention and XSS prevention.

For example, an order API should reject an invalid quantity, calculate protected prices from trusted business data and prevent a caller from assigning an approval status they do not control. Test these as separate rules. Confirm both the response and the resulting record: an error message is not sufficient if an unauthorised change was committed.

How should we prepare?

• Define scope: environments, hostnames, API versions, documentation, partner connections and exclusions.

• Provide representative access: test accounts for each role and at least two tenants where tenant isolation matters.

• Explain expected behaviour: permitted actions, sensitive fields, state transitions and high-value business operations.

• Agree safe operation: test data, request limits, destructive-action restrictions, monitoring contacts and stop conditions.

• Plan remediation: identify owners and arrange time to investigate findings and retest fixes.

OpenAPI specifications and request collections help testers understand intended behaviour. Compare them with deployed endpoints, because undocumented and retired routes may still be reachable.

How do tools and development checks fit together?

Tools need explicit environment boundaries, appropriate roles and safe request limits. An OpenAPI import does not prove that every deployed route, tenant or workflow was tested. Keep manual review for decisions requiring business context. ZAP’s automation documentation illustrates how scope, authentication and scan jobs are configured.

Adapt the test plan to the service: a care-record API needs checks around patient and care-team access; a payment API needs checks around amounts, approvals and transaction state. Use synthetic data and agree the actual contractual or regulatory requirements. A sector label alone does not determine which laws or standards apply.

How do we turn a test into safer APIs?

Use a simple sequence with named responsibilities. Business owners explain what should be allowed; developers and platform teams explain how it works; testers verify the boundaries; the risk owner decides how unresolved issues are handled.

A useful permission matrix: a customer may view their own order, support staff may view assigned cases, and only an authorised finance role may approve a refund. Test both permitted and prohibited actions. “The API returned an error” is insufficient if the action still happened or sensitive data appeared in the response.

Before closing a finding: identify the deployed version and environment, confirm the business impact has been addressed, and retain redacted evidence of the retest. If a fix is deferred, record the risk decision, interim safeguards, owner and review date.

For the principles behind these permission checks and regression tests, see the OWASP authorisation guidance.

What should the findings tell us?

A useful finding explains the affected endpoint and role, expected and observed behaviour, reproducible evidence, business impact and a specific remediation recommendation. Test evidence should redact secrets and personal data.

Prioritise findings using exposure, privileges, data sensitivity and business consequences. Retesting should confirm the fix on the original route and related paths. A time-limited assessment samples an agreed scope; a clean report is not a guarantee that every possible weakness has been excluded.

Repeat appropriate checks after meaningful changes to authentication, permissions, tenants, API versions or critical business flows. Production monitoring complements testing by helping detect misuse between assessments.

Before accepting a report, check that it states the tested environment and dates, roles and tenants covered, exclusions, limitations, remediation priorities and retest status. Distinguish verified findings from items that need further investigation.

For management, summarise which business boundaries failed, what could be affected and the action required. For developers, provide precise reproduction conditions and a fix that addresses the cause. For operations, identify relevant monitoring and configuration changes. One audience should not have to infer its responsibilities from another team’s technical notes.

What should we monitor between assessments?

Choose events that reveal misuse of important operations: failed authentication, denied access, unexpected privilege changes, unusual exports and repeated validation failures. Correlate activity across the identity provider, gateway and application where possible. A gateway request count alone may not reveal which customer record was affected.

Record enough context to investigate, such as the operation, time, relevant account or tenant, result and correlation identifier. Exclude passwords, live tokens and unnecessary sensitive request bodies. Restrict access to logs and agree retention and incident access with suppliers. OWASP’s logging guidance explains the trade-offs.

Assign someone to investigate meaningful alerts. A burst of failures might be an attack or a broken client; check context before acting. Rehearse one agreed test event and confirm it reaches the responsible team. Feed confirmed findings into remediation and regression tests.

Common questions

Does testing our website also cover its API?

Only to the extent agreed in scope and exercised during testing. APIs may expose endpoints, roles or mobile and partner workflows that the website never uses. Ask for explicit API coverage and representative account access.

What can an automated scan miss?

Tools can help find common errors, but usually need context to judge whether a business action is allowed for a particular user or tenant. Combine appropriate automation with manual checks of permissions, business rules and multi-step flows.

Does an API gateway remove the need for testing?

No. A gateway can enforce useful controls, but the application still needs correct permissions, data handling and business logic. Test the deployed combination, including any route that could bypass the gateway.

Does HTTPS or an API key make an API secure?

No. HTTPS protects traffic in transit; an API key may identify or authorise a calling application according to its design. Neither proves that a caller can access a particular customer’s data or perform an administrative action. Test those decisions separately. See OWASP’s transport, access-control and API-key guidance.

Should testing use staging or production?

A representative staging environment with synthetic records is usually a practical place for intrusive checks. Confirm that its code, identity settings, gateway and permissions reflect production. Where production-specific checks are necessary, obtain written authorisation and agree test accounts, monitoring, limits and stop conditions. Do not include real payments, bulk messaging, deletion or load testing by default.

When should we test and retest?

Plan meaningful security testing before launch and after material changes to permissions, identity, API versions or critical workflows. Add automated regression checks to development and arrange independent assessments according to risk and contractual obligations. There is no single testing interval that suits every API. Retest fixes and related access paths, not just the original request.

What determines the time and cost?

The number of roles and tenants, business workflows, integrations and authentication methods can matter more than the raw endpoint count. Documentation quality, environment access, source-code review and retesting also affect effort. Provide these details for a scoped estimate and ask what is included and excluded. The application testing service page is the place to discuss delivery and a quotation.

Related services and further reading

For scoping, delivery and enquiries, see application penetration testing and web application penetration testing. Read the API penetration testing case study for a practical example.

For a deeper explanation of identity controls, see authentication. The OWASP API Security project maintains the risk reference used here.