1. Inventory and overview

  • All APIs are inventoried, including old versions, test and shadow APIs.
  • Every API has a responsible owner.
  • The specification (such as OpenAPI) is up to date and matches the actual behavior.
  • Outdated versions and test hosts are switched off or protected just like production (Improper Inventory).
  • Data flows to third parties are documented.

2. Authentication

  • Access only via established methods such as OAuth 2.0 or OpenID Connect, no home-grown login mechanisms.
  • Tokens have a short lifetime and are renewed and revoked cleanly.
  • Login, password reset and token issuance are protected against brute force and credential stuffing.
  • JWT signatures are verified strictly, insecure algorithms such as none are rejected.

3. Authorization

  • On every access to an object, the server checks whether exactly this user may see or change it (BOLA).
  • Every function checks on the server side whether the role may execute it, including admin endpoints (BFLA).
  • Readable and writable fields are defined by an allowlist, additional fields are rejected (BOPLA, mass assignment).
  • The default is "deny": whatever is not explicitly allowed is forbidden.

4. Input, resources and configuration

  • Every request is validated against a schema, only what is allowed passes.
  • There are limits for requests, sizes and page sizes (rate limiting, pagination).
  • Outgoing requests to user-supplied URLs are restricted to an allowlist (SSRF).
  • TLS, CORS and security headers are set correctly, error messages reveal no internal details (Security Misconfiguration).

5. Business logic

  • Sensitive flows such as purchase, booking or registration are protected against automated abuse.
  • Multi-step flows are enforced on the server side, no step can be skipped.

6. Third parties and secrets

  • Responses from third-party APIs are checked like user input, redirects are not followed blindly (Unsafe Consumption).
  • API keys, tokens and certificates are managed centrally and rotated regularly.
  • No secrets in code, Git repositories or logs.

7. Testing and evidence

  • Permissions are tested with multiple test identities, ideally with every release (CI/CD pipeline).
  • A penetration test takes place regularly. DORA requires at least yearly tests for systems that support critical or important functions.
  • Failed logins, authorization errors and anomalies are logged and monitored.
  • Findings are documented with evidence, fixed and confirmed by a retest.

Venedy checks the points from sections 3, 5 and 7 automatically: AI agents attack your API with multiple identities, and every finding comes with HTTP evidence. How Venedy works

Frequently asked questions

How often should you go through the checklist?

With every new API and every major change, and regularly as part of audits. The testing points from section 7 ideally run automatically in every release.

Does the checklist replace a penetration test?

No. The checklist shows what should be secured. Whether the protection actually holds only becomes clear in a test that attacks the API with multiple identities.

What is the checklist based on?

On the OWASP API Security Top 10 (2023), the OWASP REST Security Cheat Sheet and the OWASP Application Security Verification Standard (ASVS), complemented by the testing obligation from DORA.

Sources

Read on
ProtectionImplementing API Security RisksOWASP API Top 10 TestingAPI pentest