Why API testing matters
APIs now power web, mobile, and device experiences. The OWASP API Security Top 10 (2023) names risks such as broken object authorization and unrestricted resource consumption. A specification scan can flag related design signals, but object ownership and actual resource limits require tests of the running service.
Add SAST early in design to avoid emergency fixes and reduce downstream DAST noise. Pair this guide with the API security scanner overview for runtime considerations.
Design signals found by API SAST
- Authentication declarations: missing security schemes or operations with no security requirement.
- Sensitive inputs: credentials in query strings and request bodies without validation constraints.
- Transport and URL risks: non-HTTPS server URLs or sensitive values in path and query parameters.
- Error-handling flaws: verbose stack traces, missing RFC 7807 structure, inconsistent status codes.
- Availability issues: absent pagination, rate limiting headers, or request size limits that enable scraping and abuse.
Step-by-step SAST testing workflow
- Collect the latest OpenAPI or Swagger spec. Ensure version and servers fields are accurate.
- Upload the file in the APISAST web UI or submit it to the analysis API from CI. Choose the strict profile for a more demanding review.
- Review findings grouped by severity, rule ID, category, and contract location.
- Patch the specification: add missing auth, tighten schemas, and align error responses to RFC 7807.
- Re-run to confirm fixes and export the report for auditors.
Need a template to start? Visit the API security SAST tools page.
Integrating SAST into DevOps
CI/CD hooks
Block merges when high-severity issues are found. Store artifacts for audit trails.
Branch policies
Require an updated spec per feature branch to keep inventory current.
A scheduled job can submit each current specification to the APISAST analysis API and record report IDs for review. Build notifications with your own CI integration if a team needs them; APISAST does not provide a built-in Slack workflow.
Work through a finding from start to finish
Suppose a scan flags POST /accounts/{id}/roles because no security requirement is declared. Check whether the operation inherits a global OpenAPI requirement and whether anonymous access could ever be intended. Ask the route owner which identity may change roles, then add the appropriate security declaration to the contract. Rescan the file to confirm the design finding is resolved. The change is incomplete until integration tests show that the service rejects an anonymous request and a token without the required permission.
If the report flags a missing pagination parameter on a list route, choose a page-size bound and continuation model with the owner. Document the parameters and response shape, then load-test a deep collection. This second check matters because a declared limit parameter does not guarantee the implementation applies it. Keep the before-and-after report and the runtime test result together in the review.
Make CI failures actionable
Run the contract scan against the exact OpenAPI file in the pull request. Treat a failed API request or unreadable report as a pipeline error, not a passing scan. Decide which rule severities block a merge and which findings need human review. For an existing service with many warnings, record a baseline and focus on newly introduced problems while owners work down the backlog. Store exception reasons with an owner and review date.
Do not print the full specification or credentials into CI logs. APISAST saves submitted files and reports, so review that data flow before scanning internal contracts. The CI/CD guide includes a concrete request to the backend analysis endpoint and explains a simple severity gate.
Choose follow-up tests by risk
A contract scan is strongest at repeatable declaration checks. For authentication, send valid and invalid tokens to the live service. For object authorization, compare access across two users and tenants. For rate limiting, verify real 429 responses under controlled traffic. For error handling, trigger a failure and inspect the actual body for internal data. For versioning, compare old and new contracts and run consumer tests. These checks answer questions a static file cannot settle.
When a static finding does not apply, explain why rather than deleting a useful rule. An intentionally anonymous operation should be documented as such; a gateway-enforced quota should appear in developer docs even if the application code has no limiter. Review those decisions when the endpoint changes. This keeps the report useful as a design conversation instead of a score to optimise.
FAQs about SAST for APIs
Do I need source code?
No. APISAST works directly on OpenAPI/Swagger definitions so platform teams can evaluate third-party services, too.
How often should I run scans?
On every pull request and nightly across all published specs to prevent drift.
What about GraphQL?
APISAST accepts OpenAPI and Swagger files, not native GraphQL schemas. Use GraphQL-specific schema and resolver tests for GraphQL services; our GraphQL security guide explains the difference.
Next steps
Start with the home page to upload a spec, then deepen your program with API security scanner and OpenAPI security scanner resources. For tactical rollout, pair this guide with your CI templates so enforcement is automatic.