How SAST tools tackle the OWASP API Top 10

Why it matters

The OWASP API Security Top 10 (2023) is a useful way to organise API risks. A specification scan can flag design signals, such as missing security requirements or insecure server URLs. It cannot prove that a running API enforces object-level authorization or resists abuse.

Use the OpenAPI security scanner to flag missing auth, unbounded pagination, or unvalidated parameters long before an attacker probes production.

Static vs dynamic coverage

A contract scan reads declared security schemes, parameters, and responses. Runtime tests check whether the service actually enforces authorization and rate limits. Use both views because a documented control can be missing from the implementation, and an implemented control can be missing from the document.

Pair static scans with runtime tests. The order can depend on your release process, but neither result substitutes for object-level authorization and business-flow tests.

Where contract checks help

• Authentication declarations: APISAST flags a missing security scheme or an operation with no declared security requirement. Test token validation in the running service.
• Sensitive data in URLs: A key or personal data in a query parameter can leak through logs and browser history. Keep credentials in safer channels.
• Transport and error design: The scanner flags non-HTTPS server URLs, missing error responses, and error schemas that may expose internal details.
• Resource consumption: A missing pagination parameter or undocumented rate limit header deserves review. Load tests must confirm actual limits.
• Object and function authorization: Test ownership and role rules with multiple identities. An OpenAPI file cannot prove that these checks run.

Match a risk to the right evidence

The OWASP API Security Top 10 (2023) includes broken object-level authorization, broken authentication, unrestricted resource consumption, and improper inventory management. A missing OpenAPI security requirement may support a broken-authentication review, but it does not prove that an endpoint accepts anonymous calls. A missing pagination parameter may point to resource-consumption risk, but only a load test can show whether the service is actually unbounded.

For object-level authorization, write tests with two users and resources in separate tenants. For inventory, compare deployed routes and gateway traffic with documented operations. For sensitive business flows, model abuse sequences such as bulk reservations or repeated password reset requests. Each risk needs evidence from the implementation, not a label copied from a static finding.

Know what APISAST actually checks

APISAST has rules for missing security schemes, operations without declared authentication, API keys in query parameters, non-HTTPS server URLs, sensitive URL parameters, absent pagination, and undocumented rate limit headers. It also checks error response schemas for missing problem-details fields or debug-looking names. These are useful design signals in an OpenAPI or Swagger file. They are not an OWASP certification or a complete implementation assessment.

The scanner cannot inspect resolver code, test a gateway quota, discover every shadow endpoint, or validate that an authenticated caller owns a specific object. Pair the contract scan with a route inventory, integration tests, and controlled runtime probes. When a report warns about a declaration, ask whether the specification is outdated or the service is missing a control; both cases need an owner and a verifiable fix.

Turn findings into an actionable review

Start with a sensitive operation and identify its data, caller, and expected permission. Inspect the OpenAPI declaration, then send an anonymous request and a request from another tenant in a test environment. If the declaration is missing but the service enforces auth, update the contract. If the declaration exists but runtime tests fail, fix the service. Record the finding, remediation, and retest result together so a reviewer can see what changed.

Prioritise by exposure and impact rather than by a raw count of warnings. A public administrative write route needs urgent attention; a missing description on an internal read route may be less urgent. Use the API testing methods guide to select a method for the remaining questions.

Workflow example

Add a CI job that submits the current OpenAPI file to the API security SAST tools backend. Review error-severity findings and record exceptions with an owner. Run separate tests against protected endpoints with multiple identities, then compare runtime failures with the contract baseline.

Best practices

• Keep one canonical OpenAPI spec per service; avoid drift.
• Tag sensitive operations and bind them to narrow scopes.
• Return RFC 7807 problem details for predictable monitoring.
• Cross-link findings to the SAST testing for APIs guide.
• Offer a self-service scan so consumers can verify your contract.