Unified Zero Trust CNAPP 
Secure APIs 
Secure Kubernetes 
SIEM 
Secure Secrets 
OWASP API Security Top 10: The Complete Testing Checklist (2026)
Why You Need a Dedicated OWASP API Compliance Checklist The OWASP API Top 10 is increasingly referenced by PCI-DSS, HIPAA, GDPR, and DORA auditors, and it’s a framework you need to demonstrate compliance with, repeatedly, with evidence. This checklist is tool-agnostic by design.It tells you what must be tested, what evidence is required to demonstrate […]
Reading Time: 13 minutes
Table of Contents
Why You Need a Dedicated OWASP API Compliance Checklist
The OWASP API Top 10 is increasingly referenced by PCI-DSS, HIPAA, GDPR, and DORA auditors, and it’s a framework you need to demonstrate compliance with, repeatedly, with evidence.
This checklist is tool-agnostic by design.It tells you what must be tested, what evidence is required to demonstrate compliance, and where in the API lifecycle each check belongs: design, pre-production, or runtime. Use this as an internal audit template, a developer security gate, a quarterly posture review framework, or a starting point for mapping API security to broader regulatory obligations.
It covers the OWASP API Security Top 10 (2023 edition), the current authoritative reference. Each section includes: the risk definition, the compliance question you must answer, specific tests to run and evidence to collect.
Then move to: API3, API5, API8. Finish with API6, API7, API10 based on your architecture.
How to Use This Checklist
Each OWASP API risk maps to three checklist dimensions:
Dimension | What It Means |
Test coverage | What scenarios must be exercised to claim coverage |
Evidence standard | What artifact proves the test ran and the control holds |
Lifecycle placement | Design-time, pre-production (CI/CD), runtime, or all three |
A “pass” requires evidence at the appropriate lifecycle stage. Gateway logs and WAF alerts alone are not sufficient evidence for most OWASP API compliance claims; they only capture what the perimeter sees, not what internal services expose or how authorisation behaves across object types.
API1: Broken Object Level Authorization (BOLA)
Design Pre-Production Runtime
What it means: A logged-in user changes an ID in a request (e.g. /orders/1234 → /orders/1235) and gets someone else’s data. The API never checks if they own that object.
WHAT TO TEST
- Use User A’s token to request objects belonging to User B — expect a 403 or 404, not a 200
- Test every object type: orders, documents, transactions, settings — not just user profiles
- Check vertical escalation: can a regular user reach admin-level objects?
- In multi-tenant apps, can Tenant A access Tenant B’s data?
- Confirm authorization happens server-side, not based on client-sent parameters
EVIDENCE REQUIRED → Request/response pairs showing cross-user access was blocked → A matrix mapping each object type to an authorization test → Server-side audit logs of denial decisions (not just gateway logs) |
API2: Broken Authentication
Design Pre-Production Runtime
What it means: Weak or flawed authentication allows attackers to steal tokens, brute-force credentials, or bypass login entirely, including through JSON Web Token (JWT) tricks or OAuth misconfigurations.
WHAT TO TEST
- Confirm every endpoint requires auth, old, internal, and admin endpoints
- Test JWT flaws: alg:none bypass, algorithm confusion, weak secret brute-forcing
- Verify tokens expire after logout and after their TTL
- Test OAuth: redirect URI validation, PKCE for public clients, state parameter anti-CSRF
- Confirm rate limiting and lockout on login endpoints (credential stuffing protection)
- Check that auth errors are generic, with no username enumeration via different error messages
EVIDENCE REQUIRED → Pen test report covering token validation and credential attack resistance → Config screenshots showing token TTL, rotation, and revocation settings → Rate-limiting logs from login endpoints under simulated attack |
API3: Broken Object Property Level Authorization
Design Pre-Production
What it means: APIs expose fields users shouldn’t see (e.g. internal IDs, other users’ PII), or accept writes to fields they shouldn’t control (e.g. sending role: admin in a signup request).
WHAT TO TEST
- Check every API response: are sensitive fields (PII, credentials, financial data) filtered by role?
- Mass assignment test: submit isAdmin: true, balance: 9999 in POST/PATCH — they should be ignored
- Verify read-only fields can’t be changed through any write endpoint
- For GraphQL: test introspection, field-level resolver auth, and query depth limits
EVIDENCE REQUIRED → Response diff showing different fields returned per role → Mass assignment test results (request/response pairs) → Schema audit confirming docs match what the API actually returns |
API4: Unrestricted Resource Consumption
Design Pre-Production Runtime
What it means: No rate limits, no payload size caps, and no query complexity limits, opening the door to denial of service, excessive cloud costs, or brute-force enumeration.
WHAT TO TEST
- Rate limiting enforced per-user, per-IP, and per-API key on all key endpoints
- Try bypassing rate limits: spoof X-Forwarded-For, spread requests across IPs, slow-rate attacks
- Oversized request bodies should be rejected on all POST/PUT/PATCH endpoints
- List endpoints must cap the limit parameter — no unbounded queries
- GraphQL: enforce query depth, complexity, and field count limits
EVIDENCE REQUIRED → Rate limit config exports or policy-as-code definitions → Load test results showing limits hold at defined thresholds → Log samples showing 429 responses with Retry-After headers |
API5: Broken Function Level Authorization
Design Pre-Production Runtime
What it means: Regular users can call admin-level functions directly — user management, bulk deletes, config changes — simply by knowing the endpoint URL.
WHAT TO TEST
- Map every endpoint and assign a required privilege level — including undocumented ones
- Call every privileged endpoint using a standard user token
- Test HTTP method substitution: if GET is protected, try POST/DELETE on the same path
- Check for bypass via parameters: ?admin=true, ?role=admin
- Internal endpoints like /actuator, /metrics, /admin must be locked down or unexposed
- Old API versions must enforce the same access controls as current ones
EVIDENCE REQUIRED → Full endpoint inventory with privilege classification → Pen test results covering privileged endpoint protection → Access control policy documentation per function category |
API6: Unrestricted Access to Sensitive Business Flows
Design Pre-Production Runtime
What it means: Critical flows – checkout, OTP validation, promo redemption, and account creation can be scripted and abused at scale without API-level safeguards beyond basic rate limits.
WHAT TO TEST
- Can each critical flow be scripted and repeated at scale without triggering a block?
- OTP/verification endpoints: are attempt limits, expiry, and single-use invalidation all enforced?
- Multi-step flows: can you skip a step and jump straight to the end (e.g. skip payment)?
- Voucher/promo endpoints: can a single user enumerate and redeem codes at scale?
- Race conditions: test concurrent requests on the same resource (double-spend, duplicate coupons)
EVIDENCE REQUIRED → Business flow inventory with documented abuse scenarios → Automation test results showing controls hold under scripted load → Sequence validation results confirming step-order enforcement |
API7: Server-Side Request Forgery (SSRF)
Design Pre-Production Runtime
What it means: API fetches a URL supplied by the user and an attacker points it at internal services, cloud metadata endpoints (169.254.169.254), or internal IP ranges.
WHAT TO TEST
- Find every parameter that accepts a URL, file path, hostname, or webhook destination
- Test internal targets: 127.0.0.1, 10.x.x.x, 169.254.169.254 (cloud metadata)
- Test non-HTTP schemes: file://, gopher://, ftp:// — all should be rejected
- Blind SSRF: use DNS callbacks to detect fetches that don’t show up in responses
- Webhook/callback URLs: validate against an explicit allowlist only
EVIDENCE REQUIRED → Inventory of all URL-accepting parameters → SSRF test results with blocked internal-target requests documented → Webhook/callback allowlist configuration |
API8: Security Misconfiguration
Design Pre-Production Runtime
What it means: Verbose error messages, permissive CORS, exposed debug endpoints, missing security headers, or weak TLS — simple misconfigurations that hand attackers easy wins.
WHAT TO TEST
- TLS 1.0/1.1 disabled; TLS 1.2+ enforced with strong cipher suites
- Security headers present on all responses: HSTS, X-Content-Type-Options, CSP
- CORS: no wildcard * on authenticated endpoints — origins must be allowlisted
- Error responses: no stack traces, internal paths, or DB errors in production
- Debug/management endpoints disabled in production: /swagger-ui, /actuator, /env
- Default credentials and sample API keys removed from all environments
EVIDENCE REQUIRED → Security header scan report → TLS configuration export or scan output → Confirmed list of disabled debug endpoints in production |
API9: Improper Inventory Management
Design Pre-Production Runtime
What it means: APIs that nobody remembers deploying old versions, shadow services, forgotten internal endpoints exist with weaker (or no) security controls and go undetected.
WHAT TO TEST
- Maintain an authoritative inventory: endpoint, version, auth requirements, data classification, owner
- Run continuous discovery to detect endpoints not in the inventory
- Inventory east-west (internal service-to-service) traffic — not just public APIs
- All deprecated versions still receiving traffic must have a documented sunset timeline
- Old API versions must enforce the same auth controls as current ones — no weaker controls
EVIDENCE REQUIRED → API inventory export with version and ownership fields populated → Discovery scan delta report (inventory vs. what’s actually running) → Deprecation policy with enforcement dates |
API10: Unsafe Consumption of APIs
Design Pre-Production Runtime
What it means: App blindly trusts responses from payment processors, identity providers, or data enrichment services a compromised upstream API can inject malicious data straight into your system.
WHAT TO TEST
- List every third-party API your app consumes and document the data flow
- Validate all third-party responses against an expected schema before processing
- Sanitize third-party data for injection (SQL, command, HTML) before storing or using it
- Validate TLS certs on all outbound API connections — reject invalid or expired certs
- Test what happens with an unexpected schema or malformed response — app should degrade gracefully
- API keys and OAuth tokens for third-party services must be in a secrets manager, not in code
EVIDENCE REQUIRED → Third-party API inventory with data flow documentation → Schema validation test results for third-party response handling → Secrets management config for all external API credentials |
Compliance Evidence Matrix (Best for Security Docs)
| Evidence Category | What Must Be Produced | Example Artifact | Why It Matters |
|---|---|---|---|
| Test Execution Records | Timestamped logs of API tests | Request/Response logs, scan output | Proves the control was actually tested |
| Coverage Documentation | Mapping of APIs to OWASP scenarios | Endpoint coverage report | Shows testing across all API versions and internal endpoints |
| Remediation Records | Documentation of fix + retest | Issue tracker ticket + validation scan | Demonstrates vulnerability closure |
| Continuous Evidence | Ongoing monitoring data | Runtime telemetry, security dashboards | Proves the control works over time |
Checklist Lifecycle Summary
| OWASP Risk | Design | Pre-Production | Runtime |
|---|---|---|---|
| API1: BOLA | Define object auth requirements | Dynamic access control testing | Behavioral analytics |
| API2: Broken Auth | Auth scheme review | Auth flow testing | Anomaly detection |
| API3: Property Auth | Schema and role definitions | Role-based response testing | Data exposure monitoring |
| API4: Resource Limits | Rate limit policy definition | Load and abuse testing | Consumption monitoring |
| API5: Function Auth | Privilege taxonomy | Privileged endpoint testing | Anomaly detection |
| API6: Business Flows | Abuse scenario modeling | Automation and sequence testing | Behavioral analytics |
| API7: SSRF | Input handling policy | SSRF-focused dynamic testing | Egress monitoring |
| API8: Misconfiguration | Configuration baseline | Misconfiguration scanning | Drift detection |
| API9: Inventory | Inventory registration | Coverage gap analysis | Continuous discovery |
| API10: Third-Party APIs | Third-party risk assessment | Integration testing | Outbound monitoring |
Common Checklist Failures (And How to Avoid Them)
| ❌ | Only testing gateway-visible APIs. OWASP API9 and real-world breach data make clear that internal service-to-service (east-west) traffic is a primary attack surface. Your checklist must explicitly cover east-west flows, not just publicly routable endpoints. |
| ❌ | Using generic scan results as BOLA or BFLA evidence. API1 and API5 failures are business-logic problems. Automated scanners without realistic authentication and object modeling produce false negatives. Evidence requires tests that actually use valid tokens across different user contexts. |
| ❌ | Treating version 1 coverage as covering all versions. API9 explicitly calls out unmanaged versioning. Your checklist must cover all deployed API versions, including legacy or deprecated ones still receiving traffic. |
| ❌ | One-time scans for runtime risks. Authorization drift, new shadow endpoints, and behavioral abuse patterns cannot be proven with periodic snapshots. Runtime controls require continuous evidence, not annual test records. |
| ❌ | Schema coverage without runtime validation. Contract-based checks catch what the spec says. They do not catch what the deployed API actually does under real authentication conditions. Both layers are required for credible compliance evidence. |
Using This Checklist in Practice
| ✅ | For internal audits: Run through each section quarterly. Assign ownership of each OWASP risk to a team or individual. Use the evidence requirements to define what a “closed” audit finding looks like before you begin. |
| ✅ | For developer security gates: Extract the pre-production checklist items and convert them into CI/CD acceptance criteria. A build that has not passed BOLA, broken auth, and misconfiguration checks against a staging environment should not proceed to production without a documented exception. |
| ✅ | For regulatory submissions: Use the framework cross-reference table to map your OWASP evidence artifacts to the specific regulatory control they satisfy. Auditors increasingly accept OWASP API compliance evidence as supporting documentation for PCI-DSS 6.x and HIPAA technical safeguards. |
| ✅ | For continuous posture: Use the runtime column as a monitoring design checklist. Each item represents a signal your runtime layer should be producing and routing to SIEM or an operations team. |
AccuKnox API Security Resource Hub
Explore AccuKnox’s complete API security knowledge base:
- API Security Posture Management – How AccuKnox extends CNAPP to full API lifecycle management
- 10 Best API Security Tools in 2026 – Comprehensive comparison of runtime and testing tools
- API Discovery & Visibility – How AccuKnox uses eBPF to find every API endpoint.
- API Security Help Docs
FAQ
Is this checklist sufficient for a PCI-DSS API security audit?
It covers the technical testing requirements that map to PCI-DSS 6.2 and 6.4 for APIs, but PCI-DSS compliance also requires process controls, training, and governance artifacts beyond technical testing. Use this as the technical layer of a broader compliance program.
How often should I run through the full checklist?
Pre-production checks should run with every significant API change. The full checklist — including runtime posture validation — should be reviewed at least quarterly, or after any significant infrastructure change, API versioning event, or third-party integration update.
Do I need to test east-west (internal service-to-service) traffic separately?
Yes. East-west API calls account for the majority of API traffic in microservices environments and are the primary path for lateral movement in API-related breaches. Your inventory (API9) and access control evidence (API1, API5) must explicitly include east-west coverage to be credible.
What is the minimum viable testing stack to cover all 10 risks?
At minimum: one dynamic testing tool with realistic authentication modeling (for API1–API7), one configuration scanning step (for API8), one inventory/discovery mechanism (for API9), and one third-party API integration review process (for API10). Runtime visibility should be layered on top for continuous evidence.
How do I prioritize if I cannot cover all 10 risks at once?
Start with API1 (BOLA), API2 (Broken Auth), and API9 (Inventory). These three drive the majority of real-world API breaches and are the most commonly cited gaps in API security audits. Once covered, add API3, API5, and API8. API6, API7, and API10 follow based on your specific business model and third-party dependency profile.
Get a LIVE Tour
Ready For A Personalized Security Assessment?
“Choosing AccuKnox was driven by opensource KubeArmor’s novel use of eBPF and LSM technologies, delivering runtime security”
Golan Ben-Oni
Chief Information Officer
“At Prudent, we advocate for a comprehensive end-to-end methodology in application and cloud security. AccuKnox excelled in all areas in our in depth evaluation.”
Manoj Kern
CIO
“Tible is committed to delivering comprehensive security, compliance, and governance for all of its stakeholders.”
Merijn Boom
Managing Director
