Skip to content
Sovereign SecureSovereign Secure

API Security Checklist: 20 Checks Mapped to the OWASP API Top 10

A free 20-point API security checklist mapped to the OWASP API Security Top 10: authorisation, authentication, data exposure, rate limits and what a pen test adds.

By Sovereign SecureUpdated 8 min read

Scope your pen test online 

On this page
  1. API security checklist: best practices to check before every release
  2. How does the checklist map to the OWASP API Security Top 10?
  3. What does an API pen test add to a checklist?
  4. Why do APIs need their own penetration test?
  5. How is an API penetration test run?
  6. Do PCI DSS and ISO 27001 require API testing?
  7. How much does API penetration testing cost?
  8. Why Sovereign Secure
  9. Next step

An API security checklist is a list of the controls every API should have in place, from an up-to-date inventory to server-side authorisation checks and rate limits. This API security testing checklist has 20 checks, each tagged to its category in the OWASP API Security Top 10 (2023), so your developers can review an API before release and between penetration tests. You can copy the table below or download the checklist as a spreadsheet (.xlsx, free) to track status, owners and evidence.

API penetration testing is the manual, authorised test that checks whether those controls hold up under attack. A tester works through the API as different users and roles to find the authorisation, authentication, data exposure and business logic flaws that automated scanners miss; our API penetration testing services page explains how we scope and run one.

Key takeaways

  • The OWASP API Security Top 10 (2023) is the standard baseline for an API security checklist.
  • The most damaging API flaws are authorisation and business logic issues, which scanners cannot see.
  • A checklist confirms controls exist; a penetration test confirms they work under attack.
  • APIs need testing in their own right; a web front-end test does not cover every endpoint behind it.
  • Any API that handles cardholder data, or can affect its security, is in PCI DSS scope.

API security checklist: best practices to check before every release

Use this checklist to review an API before release or between penetration tests. Each item is a best practice your developers should be able to show is in place, tagged with the OWASP API Security Top 10 (2023) risk it prevents.

# Area Check OWASP API risk
1 Inventory ☐ Every API, version and environment is documented, with an owner API9
2 Inventory ☐ Deprecated versions are switched off, not just hidden API9
3 Inventory ☐ Documentation and test consoles are not publicly exposed unless intended API8, API9
4 Authentication ☐ Every endpoint requires authentication unless it is deliberately public API2
5 Authentication ☐ Tokens are signed, validated on every request, short-lived and revocable API2
6 Authentication ☐ Password reset and account recovery cannot be used to take over accounts API2
7 Authentication ☐ Credential stuffing is limited by rate limiting and, where possible, MFA API2
8 Authorisation ☐ The server checks object ownership on every request that takes an ID API1
9 Authorisation ☐ Administrative functions check the caller’s role on the server API5
10 Authorisation ☐ Clients cannot set sensitive fields such as role, price or account status API3
11 Data exposure ☐ Responses return only the fields the caller needs API3
12 Data exposure ☐ Error messages do not reveal stack traces, queries or internal hostnames API8
13 Data exposure ☐ Sensitive data is encrypted in transit with current TLS settings API8
14 Input and limits ☐ All input is validated against a schema, including nested and GraphQL input General (injection)
15 Input and limits ☐ Rate limits, payload size limits and pagination limits are enforced API4
16 Input and limits ☐ Server-side fetching of user-supplied URLs is restricted to an allow-list API7
17 Business logic ☐ Multi-step workflows cannot be skipped, replayed or reordered API6
18 Business logic ☐ Quantities, prices and balances are validated on the server API3, API6
19 Logging ☐ Authentication failures, authorisation failures and unusual volumes are logged and alerted on General (logging)
20 Third parties ☐ Data received from partner and third-party APIs is validated before use API10

Items marked “General” cover injection and insufficient logging, which were categories in the 2019 edition of the list but not the 2023 one. They are still baseline controls. The spreadsheet version adds status, owner and evidence columns, so you can attach it to a release or a pen test scope.

How does the checklist map to the OWASP API Security Top 10?

Each risk in the OWASP API Security Top 10 (2023) has a checklist control your developers can review and a check a penetration tester runs to prove the control works:

OWASP API risk (2023) Checklist control What the pen tester checks
API1 Broken object level authorisation The server checks object ownership on every request that takes an ID Each user can only reach the objects they own
API2 Broken authentication Every endpoint authenticated; tokens signed, validated, short-lived and revocable Token issuance, expiry, revocation and password reset
API3 Broken object property level authorisation Responses return only the fields needed; clients cannot set sensitive fields Responses do not over-share fields; clients cannot update protected fields
API4 Unrestricted resource consumption Rate, payload size and pagination limits enforced Rate limits, pagination limits and query complexity limits
API5 Broken function level authorisation Administrative functions check the caller’s role on the server Standard users cannot call administrative functions
API6 Unrestricted access to sensitive business flows Multi-step workflows cannot be skipped, replayed or reordered Sign-up, checkout and similar flows cannot be abused at scale
API7 Server-side request forgery Server-side fetching of user-supplied URLs restricted to an allow-list URLs supplied by users cannot make the server reach internal systems
API8 Security misconfiguration Errors reveal nothing internal; current TLS; documentation not exposed Error handling, CORS, TLS and exposed documentation
API9 Improper inventory management Every API, version and environment documented; deprecated versions switched off Old versions and undocumented endpoints are retired or protected
API10 Unsafe consumption of APIs Data from partner and third-party APIs validated before use Data from third-party APIs is validated, not trusted blindly

What does an API pen test add to a checklist?

A checklist shows that controls exist. Scanning finds known weaknesses quickly. A penetration test shows whether the controls hold when someone actively tries to get round them:

Aspect Checklist review Automated API scanning API penetration testing
Who or what Your developers or security team A tool, often in the build pipeline A skilled tester, supported by tools
Shows Whether controls are designed and documented Known vulnerabilities, missing headers, some injection, outdated components Whether controls hold under attack, including authorisation, logic and multi-step abuse
Understands users and roles Only as far as the reviewer checks No Yes, tests each role against the others
Frequency Before each release Every build or release Annually and after significant change
Output Gaps to fix Tool findings for triage Evidenced findings, impact and fixes, then a retest

Scanning still has a place for routine hygiene. Our comparison of penetration testing vs vulnerability scanning explains how the two fit together.

Why do APIs need their own penetration test?

Because the API, not the user interface, is where access decisions are actually enforced. Modern applications are often thin front ends on top of APIs, and mobile apps and partners talk to those APIs directly. If the API trusts whatever the client sends, a well-formed, authenticated request can quietly return someone else’s data.

Two problems come up repeatedly:

  • Forgotten endpoints. Old API versions, debug routes and internal endpoints exposed by mistake often lack the controls applied to the current production API.
  • Authorisation that trusts the client. If the API returns a record because the request included its ID, without checking the caller is entitled to it, any logged-in user may be able to read other users’ records.

Firewalls and web application firewalls rarely stop these issues, because nothing about the request looks malicious.

How is an API penetration test run?

  1. Scoping. Agree the APIs, environments, user roles, and any endpoints to exclude or rate-limit.
  2. Preparation. You provide documentation (OpenAPI or Postman collections) and at least two test accounts per role, so testers can check one user against another.
  3. Testing. Manual testing supported by tooling, with immediate notification of anything critical.
  4. Reporting. An executive summary for management, and technical findings with evidence, risk ratings and specific fixes. Our guide to reading a penetration testing report shows what good looks like.
  5. Retesting. Once fixes are deployed, they are verified and the report is updated.

If your APIs sit behind a customer-facing site, it is usually efficient to scope web application penetration testing in the same engagement. For mobile apps, see our mobile app security testing checklist.

Do PCI DSS and ISO 27001 require API testing?

Neither names APIs specifically, but both catch them.

Standard What applies to APIs
PCI DSS v4.0.1 APIs that store, process or transmit cardholder data, or can affect its security, are in scope. Requirement 11.4 requires penetration testing covering application-layer attacks at least every 12 months and after significant change. Requirement 6.2.4 lists attacks on business logic, including API abuse, among those bespoke software must be built to resist.
ISO/IEC 27001:2022 Annex A controls 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance) expect you to find and fix technical weaknesses. API test reports are direct evidence.
UK GDPR Article 32 requires a process for regularly testing the effectiveness of security measures for personal data.

For payment APIs, PCI penetration testing should be scoped so the report stands up at your assessment.

How much does API penetration testing cost?

Cost follows the number of tester-days, which depends on the number of endpoints, user roles, authentication methods and how complex the business logic is. Documentation and test accounts reduce the days needed, because testers do not have to rebuild your API map. Our guide to penetration testing cost shows typical UK ranges and what drives them.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. Where an API sits in PCI DSS scope, we scope the test with the assessor’s evidence requirements in mind. Where source code is available, a source code review alongside testing gives the deepest coverage.

Next step

To have your APIs tested against this checklist, see how we scope and run API penetration testing for REST, GraphQL and SOAP. If you already know your endpoints and roles, our penetration testing quote form gets you a fixed price.

Free tools and services

FAQ

Questions we often hear

Can't find your answer? Call us on +44 161 523 5276 or send us a message.

What should an API security checklist include?

At minimum: an inventory of every API and version, authentication on every endpoint, server-side checks on every object and function a caller requests, minimal data in responses, input validation, rate and size limits, protected business flows, and logging of authentication and authorisation failures. The OWASP API Security Top 10 is the usual baseline.

What is API penetration testing?

A manual, authorised security test of the endpoints behind your applications, carried out as different users and roles to find authorisation, authentication, data exposure and business logic flaws. Our API penetration testing services page explains how a test is scoped and run.

What is the difference between a web application pentest and an API pentest?

A web application test works mainly through the browser interface. An API test goes straight to the endpoints behind it, focusing on authorisation, data exposure and business logic in machine-to-machine traffic. Many engagements cover both.

How often should we test our APIs?

At least annually and after significant change, such as new endpoints, a new authentication model or a major release. PCI DSS Requirement 11.4 sets the same baseline for systems in or connected to the cardholder data environment.

Do you need our source code?

No. A grey-box test with API documentation (OpenAPI or Postman collections) and test accounts for each role gives much better coverage in the same number of days. Source code review can be added if you want the deepest coverage.

Will testing disrupt our live services?

Testing in a staging environment that mirrors production is preferred. Where production testing is needed, testing windows, rate limits and excluded endpoints are agreed in advance, and testing stops immediately if anything behaves unexpectedly.

Can an automated API scanner replace a penetration test?

No. Scanners find known vulnerabilities and misconfigurations, but they cannot tell that one user should not see another user's records, or that an order total should never be negative. Those flaws need a person to test them.

Free consultation

Speak to an assessor

We aim to reply within one working day, and send a fixed quote once your scope is confirmed.

  • PCI SSC-approved QSA, QPA, CPSA, P2PE and 3DS assessors
  • IASME-licensed Cyber Essentials certification body
  • Clients across the UK, US, Europe, Middle East and Asia since 2012

“The Cyber Security Services were delivered on time and price was competitive.”

Beverley McGowan, Director, Specialists Hub. Read the full testimonial

By sending this form you agree to us contacting you about your enquiry. See our privacy policy.

We aim to reply within one working day. The first consultation is free.