API Security Review Template (OWASP API Top 10 2023, ASVS 5.0)

API Security Review: [API name and version]

Security review record for one API (REST, GraphQL, gRPC gateway or WebSocket): scope and context, review method and evidence, API inventory and exposure, data flow and trust boundaries, a structured review against each of the ten risks of the OWASP API Security Top 10 2023, a checklist of the API-relevant chapters of the OWASP Application Security Verification Standard (ASVS) 5.0.0 (May 2025), a scored findings register, risk summary, remediation plan, retest and sign-off. Versions as checked in October 2026. The questions, structure and examples are original. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Scope and context
2. Method, evidence and rating
3. API inventory and exposure
4. Data flow and trust boundaries
5. Review against the OWASP API Security Top 10 2023
6. ASVS 5.0.0 API checklist
7. Findings register
8. Risk summary and decision
9. Remediation plan and retest
10. Sign-off and next review
11. Glossary and references

1. Scope and context

In scope: [all operations under /v2/, the webhook delivery service, the GraphQL tracking endpoint, gateway policies, token validation].

Out of scope (with reason): [the identity provider itself (reviewed in IAM review IAM-2026-03), the mobile app binaries (covered by the mobile app security assessment), denial-of-service load testing (scheduled separately)].

Rules of engagement: testing accounts [list], allowed time windows, production actions limited to [read-only requests with test tenants], emergency contact [@on-call].

2. Method, evidence and rating

The review combines four evidence sources. Record which ones you used for each risk in section 5.

Rating method. Rate each finding for likelihood (1 to 5) and impact (1 to 5) and multiply them. Use your organisation's risk method if it has one, and record the mapping here.

Where your vulnerability management policy requires CVSS, add a CVSS v4.0 vector in the finding detail and keep this score as the business rating. Test accounts used: [User A in Tenant 1, User B in Tenant 1, User C in Tenant 2, Partner client P1, administrator ADM1].

3. API inventory and exposure

Example counts for the /v2 surface: 46 operations were seen in gateway logs over 30 days and 41 of them are in the specification, so 5 operations (10.9%) are undocumented and documentation covers 89.1% of the live surface. Each undocumented operation is listed below and either documented, retired or raised as a finding.

4. Data flow and trust boundaries

5. Review against the OWASP API Security Top 10 2023

The OWASP API Security Top 10 2023 is still the current edition of the list as of October 2026 (owasp.org/API-Security). Risk IDs and short names are cited for mapping.

5.1 API1:2023 Broken Object Level Authorization

Questions:

• Does every operation that takes an object identifier (path, query, body, header) check that the caller may access that specific object, in the service and not only in the client?
• With User A's token, can you read, change or delete an object that belongs to User C in another tenant by changing the identifier?
• Are identifiers random, and does the design still check authorization (random IDs reduce guessing, they do not replace the check)?
• Are bulk and list operations filtered by the caller's tenant on the server?

ASVS 5.0.0: 8.2.2, 8.3.1, 8.4.1. Result: Example: Finding APISR-001 (GET /v2/shipments/{id} returns another tenant's shipment).

5.2 API2:2023 Broken Authentication

Questions:

• Which operations accept no authentication, and is each one intended (list them)?
• Are access tokens validated for signature, allowed algorithm, issuer, audience and expiry on every request?
• Are credential and token endpoints protected against brute force and credential stuffing?
• How long do access and refresh tokens live, and can they be revoked?

ASVS 5.0.0: 6.3.1, 9.1.1, 9.1.2, 9.2.1, 9.2.3, 10.3.1. Result: Example: Finding APISR-009 (partner access tokens valid for 24 hours, no revocation).

5.3 API3:2023 Broken Object Property Level Authorization

Questions:

• Do responses return only the fields the caller may see, or whole database objects filtered by the client?
• Can a caller set fields they should not control (role, price, status, owner, tenant) by adding them to a request body?
• Are read and write field rules documented per role?

ASVS 5.0.0: 8.1.2, 8.2.3, 15.3.1, 15.3.3. Result: Example: Finding APISR-002 (PATCH /v2/accounts/{id} accepts role).

5.4 API4:2023 Unrestricted Resource Consumption

Questions:

• Are there limits on request rate, payload size, page size, upload size, query depth and execution time?
• Which operations trigger paid third-party calls (SMS, email, maps, rating engines), and is each one limited per caller?
• Do timeouts and limits exist on outbound calls so a slow partner cannot exhaust threads?

ASVS 5.0.0: 2.4.1, 4.3.1, 15.1.3, 15.2.2. Result: Example: Finding APISR-003 (POST /v2/quotes calls a paid rating engine without a per-client limit).

5.5 API5:2023 Broken Function Level Authorization

Questions:

• Can a normal user call administrative operations by guessing paths or changing the HTTP method?
• Are administrative operations on a separate path, audience or gateway, with role checks in the service?
• Are unused HTTP methods rejected?

ASVS 5.0.0: 8.2.1, 4.1.4, 8.4.2. Result: Example: Pass for /v2/; admin export route covered by APISR-004.

5.6 API6:2023 Unrestricted Access to Sensitive Business Flows

Questions:

• Which business flows would hurt the business if automated at scale (booking scarce slots, creating accounts, redeeming credits, scraping prices)?
• What limits each flow (per account, per device, per payment instrument), and is the limit enforced on the server?
• Do high-value flows need step-up authentication or a second approver?

ASVS 5.0.0: 2.3.2, 2.3.4, 2.3.5, 2.4.1. Result: Example: Pass: pickup slot booking is locked per slot and limited to 20 bookings per account per hour.

5.7 API7:2023 Server Side Request Forgery

Questions:

• Where does the API fetch a URL supplied or influenced by the caller (webhooks, image import, document fetch, OAuth metadata)?
• Is the destination checked against an allow-list of schemes, hosts and ports, with private, link-local and metadata addresses blocked after DNS resolution?
• Are redirects disabled for outbound calls unless needed?

ASVS 5.0.0: 1.3.6, 15.3.2. Result: Example: Finding APISR-005 (webhook URL accepts http://169.254.169.254).

5.8 API8:2023 Security Misconfiguration

Questions:

• Are TLS settings, CORS policy, security headers and content types correct on every host?
• Do error responses hide stack traces, framework versions and internal hostnames?
• Are debug modes, introspection and documentation endpoints disabled or protected in production where not meant to be public?

ASVS 5.0.0: 4.1.1, 4.3.2, 12.2.1, 13.4.2, 13.4.5, 13.4.6, 16.5.1. Result: Example: Findings APISR-006 (GraphQL introspection enabled) and APISR-007 (stack traces in 500 responses).

5.9 API9:2023 Improper Inventory Management

Questions:

• Does the inventory in section 3 match the specification, gateway and traffic?
• Do deprecated versions have a sunset date, an owner and the same controls as current versions?
• Are non-production hosts reachable from the internet, and do they hold production data?

ASVS 5.0.0: 13.1.1, 13.4.5, 15.2.3. Result: Example: Finding APISR-004 (five undocumented operations, including a debug route).

5.10 API10:2023 Unsafe Consumption of APIs

Questions:

• Which third-party APIs does this API call, and is each response validated against a schema and treated as untrusted input?
• Are TLS certificates of partners validated, and are redirects from partners refused?
• What happens if a partner returns a huge, slow or malformed response?

ASVS 5.0.0: 1.2.4, 12.3.2, 13.1.3, 15.3.2. Result: Example: Finding APISR-008 (carrier client disables certificate validation in one code path).

5.11 Summary of results

6. ASVS 5.0.0 API checklist

ASVS 5.0.0 has 17 chapters (V1 to V17). The API-relevant sections are listed below with an original one-line description of what to check. Read the requirement text in ASVS itself.

Example coverage: 13 sections listed, 1 not applicable, 12 reviewed, 3 passed, 9 with at least one finding.

7. Findings register

Detail for each finding (repeat the block):

8. Risk summary and decision

Example summary: the API has one Critical object level authorization flaw that exposes personal data across tenants, so release is blocked until APISR-001 is fixed and retested. The three High findings (APISR-002, APISR-003, APISR-005) must be fixed before partner onboarding opens. Medium and Low findings follow the target fix times in section 2.

Any finding the owner chooses to accept rather than fix needs a security exception with an expiry date, recorded through the security exception request process.

9. Remediation plan and retest

Preventive actions beyond the individual fixes:

• Example: Add an authorization test matrix (role x operation x tenant) to the API contract tests.
• Example: Generate the gateway route list from the specification so undocumented routes fail the build.
• Example: Add the review checklist in section 6 to the API design review gate.

10. Sign-off and next review

11. Glossary and references

Standard and licence note

Based on the OWASP API Security Top 10 2023 and the OWASP Application Security Verification Standard 5.0.0, both published by the OWASP Foundation under CC BY-SA 4.0. Risk IDs and short names and ASVS chapter, section and requirement numbers are cited for mapping only; the review questions, structure and examples are original and no OWASP description or requirement text is reproduced, so no ShareAlike obligation arises from this template. If you paste OWASP text into your copy, that adapted material is under CC BY-SA 4.0, must credit OWASP and must be shared alike. Check the current OWASP versions at owasp.org before relying on the mapping. Template licence: MIT.