In 2023, the OWASP API Security Top 10 got its first revision since 2019, adding new categories like Unsafe Consumption of APIs and Server-Side Request Forgery because attackers had moved past textbook injection flaws into abusing business logic. That shift shows up in the incident data: Postman's 2023 State of the API Report found 74% of respondents said API-related security incidents at their organization had increased year over year, and T-Mobile disclosed in January 2023 that an unauthenticated API endpoint had exposed data on 37 million customer accounts for roughly six weeks before detection. So what is API security testing, in practical terms? It's the systematic practice of probing authentication, authorization, input validation, rate limiting, and business logic across every documented and undocumented endpoint before an attacker does it for you. Unlike a point-in-time penetration test, it has to run continuously, because API inventories drift every sprint. This checklist covers what to test, how often, and which controls actually stop the failure modes showing up in 2024 and 2025 breach reports.
What Is API Security Testing, and How Is It Different from Web App Testing?
API security testing validates the authentication, authorization, and data-handling logic behind an interface that has no browser DOM or CSS to obscure its structure — which makes it both easier to enumerate and easier for attackers to script against at scale. A typical web app pentest checks how a UI renders and sanitizes input; API testing checks what the endpoint does when you call it directly with a modified user_id, an expired JWT, or a bulk of 10,000 sequential requests in under a minute. Gartner predicted in 2021 that by 2022 API abuse would become the most frequent attack vector for enterprise web application breaches, and Salt Security's research has repeatedly shown that API traffic now makes up more than 80% of overall web traffic at large enterprises. Because APIs are consumed by other machines rather than humans clicking through a UI, testing has to cover every version, every internal service-to-service call, and every partner integration — not just the paths a QA team happens to click through manually.
What Are the Most Critical API Vulnerabilities to Test For?
The most critical API vulnerabilities are the ones ranked in the OWASP API Security Top 10 (2023 edition), led by Broken Object Level Authorization (API1), which occurs when an endpoint returns or modifies another user's data because it trusts a client-supplied ID without checking ownership. BOLA is not theoretical: Optus disclosed in September 2022 that an internet-facing, unauthenticated API endpoint exposed the personal records of 2.1 million customers, and USPS patched a similar BOLA flaw in 2018 that let any logged-in user query the account details of its 60 million registered users. Close behind is Broken Authentication (API2) — session tokens that never expire or API keys checked into public repos — and Server-Side Request Forgery (API7), added in the 2023 revision after researchers demonstrated it repeatedly in webhook and URL-preview features. Rounding out the list: Broken Object Property Level Authorization (API3), Unrestricted Resource Consumption (API4), Broken Function Level Authorization (API5), Security Misconfiguration (API8), Improper Inventory Management (API9, i.e., shadow and zombie APIs), and Unsafe Consumption of APIs (API10), which covers blindly trusting data pulled from third-party APIs.
How Often Should APIs Be Tested — Once a Year or Continuously?
APIs need continuous testing, not an annual pentest, because endpoint inventories change faster than audit cycles can track them. Salt Security's State of API Security reports have repeatedly found API counts growing across a typical enterprise's estate by double digits year over year, and a company shipping weekly releases can add or modify dozens of endpoints a month — each one a candidate for a missed auth check. An annual pentest that sampled 50 endpoints in January tells you nothing about the 12 new endpoints merged in March. Effective programs test at three cadences: automated authorization and injection checks on every pull request that touches a route file, a full dynamic scan against a staging environment nightly or on every merge to main, and a manual business-logic review each quarter for the highest-risk flows, such as payments, account recovery, and admin functions. Anything less than PR-level automated checks leaves a gap between when a vulnerable endpoint ships and when it's ever tested.
What Belongs on an API Security Testing Checklist?
A working API security testing checklist has eight items, starting with inventory: discover every endpoint, including undocumented "shadow" APIs and deprecated "zombie" versions still running in production, since you cannot test what you don't know exists. Second, verify authentication on every route, not just the ones in the OpenAPI spec — confirm tokens expire, aren't accepted after logout, and can't be replayed. Third, test authorization per object and per function: attempt to fetch, edit, or delete a resource belonging to a different tenant or role using a manipulated ID (BOLA/BFLA). Fourth, fuzz every input field and header for injection (SQLi, NoSQLi, command injection) and malformed payloads that crash parsers. Fifth, test rate limiting and resource consumption by sending burst traffic and oversized payloads to confirm the API throttles or rejects rather than exhausting compute. Sixth, check for SSRF in any parameter that accepts a URL, and confirm outbound requests are restricted to an allowlist. Seventh, review versioning: confirm older API versions enforce the same controls as the current one, since v1 endpoints are frequently forgotten. Eighth, confirm logging captures enough detail — caller identity, endpoint, response code — to support incident response, since Salt Security has found many breached organizations couldn't reconstruct attacker activity after the fact.
Should You Use SAST, DAST, or Contract Testing for APIs?
The right answer is all three, layered at different points in the pipeline, because each catches a different class of API flaw. Static analysis (SAST) runs against source code before merge and catches missing authorization checks or hardcoded secrets in the handler logic itself — cheap to run but blind to runtime behavior. Dynamic testing (DAST), driven off the OpenAPI/Swagger spec with tools like OWASP ZAP or 42Crunch, sends live requests against a running instance and catches the BOLA, SSRF, and injection issues that only manifest when the API actually executes — this is where most of the OWASP API Top 10 gets found in practice. Contract testing compares the live API's actual responses against its published schema and flags drift, such as an endpoint quietly returning an extra internal field (an API3 property-level authorization leak) that was never in the spec. Postman's 2023 survey found that teams running automated API tests in CI caught breaking changes and security regressions measurably earlier than teams relying on manual QA passes before release, which is the core argument for wiring all three into the pipeline rather than treating any one as sufficient on its own. In practice, security testing API coverage that only runs SAST or only runs DAST leaves exactly the gap the other one exists to close.
How Safeguard Helps
Safeguard extends API security testing beyond endpoint scanning by tracing whether a vulnerable API dependency or flagged function is actually reachable from a live request path, so security teams triage the handful of findings attackers can exploit instead of every match a scanner returns. Griffin AI, Safeguard's analysis engine, correlates API inventory, authorization logic, and dependency data to flag BOLA-prone patterns and shadow endpoints automatically, then explains the exploit path in plain language for faster triage. Safeguard generates and ingests SBOMs across your API services so you always have a current, auditable inventory of what's deployed — closing the API9 (improper inventory) gap that manual spreadsheets can't keep up with. When a fix is available, Safeguard opens an auto-fix pull request with the patched dependency or corrected authorization check pre-validated against your test suite, cutting remediation time from weeks to a single review cycle.