OpenAPI Security Linter: Find Security Gaps in Your API Spec
Paste your OpenAPI or Swagger spec and this free tool lists the security gaps it can see: operations with no authentication, plain-HTTP servers, secrets in URLs, sensitive fields in responses, and more. It runs in your browser, reads JSON and YAML, and your spec is never sent anywhere.
- Free
- No signup
- Runs in your browser
- Reads JSON and YAML
- 14 checks
Runs in your browser. Your spec is not uploaded; only the YAML parsing library is downloaded from a public CDN. The checks look at the spec text only and cannot prove how the live API behaves. The example is made up. If your spec contains real credentials, rotate them.
How it works
- 1Paste your specPaste an OpenAPI 3.x or Swagger 2.0 spec, or upload the file.
- 214 checks run in your browserAuthentication, plain HTTP, secrets in URLs, sensitive fields, mass assignment and more.
- 3Fix, then test liveFindings by severity with exact places, plus the tests a spec cannot show.
How to get your OpenAPI spec
Most frameworks can export the spec for you, so find the file or URL first and paste its contents above.
- From a running API: try
/openapi.json,/v3/api-docs,/swagger.jsonor/swagger/v1/swagger.jsonon your own API. - From your code: frameworks such as FastAPI, Spring Boot (springdoc), NestJS and ASP.NET (Swashbuckle) generate it.
- From Postman or Insomnia: export the collection as OpenAPI.
What the linter checks
Each check below maps to a risk in the OWASP API Security Top 10 (2023), so you can see which part of the list a finding belongs to.
| Check | Why it matters | OWASP API risk | Rating |
|---|---|---|---|
| No authentication scheme defined | The spec describes no way to authenticate. | API2 | High |
| Write operations without authentication | POST, PUT, PATCH and DELETE operations that anyone can call. | API2 / API5 | High |
| Sensitive-looking reads without authentication | GET operations on users, orders, accounts and similar objects with no auth. | API1 / API2 | Medium |
| Plain HTTP servers | Server URLs that use http:// instead of https://. | API8 | High |
| API key or secret in the URL | API keys, tokens and passwords in query strings end up in logs, history and referrers. | API2 / API8 | High |
| Personal data in the URL | Email, phone, address and similar fields in query strings. | API3 / API8 | Medium |
| Sensitive fields in responses | Response schemas that expose password hashes, secrets, card numbers and similar. | API3 | High |
| Privilege fields accepted in requests | Request bodies that accept role, isAdmin, permissions and similar (mass assignment). | API3 | Medium |
| Credentials inside the spec | AWS keys, private keys, tokens and JWTs pasted into examples or descriptions. | API8 | High |
| Weak authentication schemes | HTTP Basic, API keys in the query, OAuth implicit and password flows. | API2 | Medium |
| Administrative or debug paths | Paths such as /admin, /actuator, /debug and /internal. | API5 / API8 | High / Info |
| Unbounded lists and no rate limits | Array responses with no paging parameters, and no documented 429 or rate-limit headers. | API4 | Low |
| Old versions and deprecated operations | Deprecated operations and several API versions still listed. | API9 | Info |
| Object IDs in paths | Every operation that takes an ID needs an ownership check. A spec cannot prove it, so test it. | API1 | Info |
Our guide to the OWASP API Security Top 10 explains each risk with examples and tests.
What a spec cannot tell you
A clean result only means the spec shows none of these patterns, because a spec describes the API and does not prove how it behaves. The biggest API risks cannot be seen in a document at all.
- Broken object-level authorization (BOLA) only shows up when you call an endpoint with a different user's token on someone else's object.
- Broken function-level authorization (BFLA) only shows up when a normal user calls an admin operation.
- Rate limits and validation are properties of the running service, not the document.
To test these on a live API, use the ScanTitan API vulnerability scanner.
What to do with the findings
Fix the high findings first, update the spec, then test the live API for the things the spec cannot show.
- Fix the high findings: missing authentication, plain HTTP, secrets in URLs and sensitive response fields.
- Remove credentials from the spec and rotate any that were real.
- Decide on each public operation: keep it public on purpose, or add a security requirement.
- Test object-level and function-level authorization with two user accounts.
- Recheck the spec after each change and keep it in your pipeline.
Frequently asked questions
What does this tool check?
It reads the OpenAPI or Swagger spec and looks for security gaps that are visible in the document: operations with no authentication, plain-HTTP servers, secrets and personal data in URLs, sensitive fields in responses, privilege fields in requests, credentials pasted into the spec, weak authentication schemes, admin or debug paths, missing paging and rate limits, and old versions.Does it test my live API?
No. It only analyses the spec text. It cannot tell whether an endpoint actually enforces authentication or ownership checks. Use the findings to decide what to test, and test the live API with two user accounts for object-level and function-level authorization.Which formats and versions does it read?
OpenAPI 3.0 and 3.1, and Swagger 2.0, as JSON or YAML. It follows local references that start with #/ and does not fetch external files.Is my spec uploaded anywhere?
No. The analysis runs in your browser. Only the YAML parsing library is downloaded from a public CDN when the page loads. Your spec is never sent to ScanTitan or anyone else.Why does it flag a login endpoint as fine but a similar path as a risk?
Login, sign-up, token and health endpoints are normally public, so the tool lists them as public by design instead of a risk. Everything else without authentication is flagged, because the spec gives no reason for it to be open.A finding is a false positive. What now?
Some findings depend on intent, such as a public read endpoint or a documentation placeholder key. Treat each finding as a question to answer. If the answer is that it is intended, document it and move on.How does this relate to the OWASP API Security Top 10?
Each check maps to one of the OWASP API Security Top 10 risks, shown in the table above. A spec can reveal the signs of most of them, but risks such as broken object-level authorization can only be confirmed by testing the running API.A spec shows what an API claims. Test what it actually does.
See the API vulnerability scannerSee pricing