OpenAPI Security Auditor

Audit an OpenAPI 2, 3 or 3.1 document for unauthenticated operations, sensitive parameters, insecure server URLs and missing limits, and get a per-endpoint risk table.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

OpenAPI or Swagger document JSON or YAML. Swagger 2.0, OpenAPI 3.0 and 3.1. Read in your browser.

Or drop a .json, .yaml or .yml file

Up to 8 MB. Read locally.

It audits the document, not the running API

This distinction runs through every finding, so it is worth putting first. An OpenAPI document describes what an API is meant to do. It cannot tell you what the implementation does - an operation marked as requiring a bearer token may not check it, and one with no security field may be fully protected.

What a document audit is genuinely good for is finding the gap between intent and description: the operation nobody remembered to mark as authenticated, the staging server URL that shipped to the developer portal, the password parameter that somehow ended up in a query string.

Broken object-level authorisation is the top item on the OWASP API Security Top 10, and it is structurally invisible to this kind of analysis. A clean report here is not a clean API.

What it checks

Authentication coverage. Which operations require credentials and which do not, accounting for global security and per-operation overrides - including the security: [] form that makes an operation public inside an otherwise protected API. State-changing public operations are graded higher than read-only ones.
Credentials in URLs. A password or token in a path or query parameter is graded critical, because query strings land in server logs, proxy logs, browser history and the Referer header. TLS does not help - the exposure is at the endpoints, not on the wire.
Insecure and internal servers. http:// server URLs, and localhost or internal hostnames that should not be in a published document. Generated clients use exactly what the document says.
Weak authentication schemes. API keys carried in the query string, HTTP Basic, and the OAuth implicit and password flows - both deprecated by the OAuth 2.0 Security Best Current Practice.
Real credentials in examples. Example values matching known token formats - JWTs, GitHub tokens, Stripe live keys, AWS key IDs, PEM private keys. An example is published wherever the document is.
Missing limits. String fields with no maxLength and arrays with no maxItems. A validator generated from a document with no limits accepts a request of any size.
Upload operations, and operations documenting no error responses - including authenticated operations that never describe a 401 or 403, which usually means nobody decided.

The YAML reader is deliberately small

YAML support here does not come from a general YAML library. It is a purpose-built reader covering the subset OpenAPI documents use, and it refuses the rest:

Anchors and aliases (&a / *a) are rejected. These are the billion-laughs expansion: nine nested aliases each referencing the previous ten times expand to a billion nodes from a few hundred bytes. OpenAPI has $ref and needs neither.
Tags (!!python/object, !!ruby/object) are rejected. Tags are how YAML deserialisation becomes remote code execution. A reader with no tag support cannot construct anything.
Merge keys (<<) are rejected for the same expansion reason.
__proto__, constructor and prototype are refused as document keys, because prototype pollution through a parsed document is a real bug class in JavaScript and refusing them costs nothing.

There are also hard caps on document size, nesting depth, line count and total keys. When a document uses something outside the subset, the reader says so and names the line - which is a considerably better outcome than silently misreading it.

Version support

Swagger 2.0, OpenAPI 3.0.x and OpenAPI 3.1.x, in JSON or YAML. The differences that matter are handled properly: Swagger 2.0 keeps security schemes in securityDefinitions and builds its base URL from host, basePath and schemes, while OpenAPI 3 uses components.securitySchemes and a servers array. File uploads are a file parameter type in 2.0 and a multipart/form-data request body in 3.x.

An unrecognised version is rejected with a clear message rather than parsed on a guess.

Nothing is uploaded

An OpenAPI document routinely names internal hostnames, staging environments and endpoints that are not otherwise published. It is read and analysed entirely in your browser, and the exports are generated locally.

Frequently asked questions

Does a clean report mean my API is secure?

No. This audits a specification, which describes intent. Broken object-level authorisation - the top item on the OWASP API Security Top 10 - is invisible to document analysis, as are rate limiting and mass assignment. Use this to fix what the document says, then verify the implementation.

Why is my YAML rejected for using anchors?

Because anchors and aliases enable the billion-laughs expansion attack, and OpenAPI has $ref for reuse. The reader refuses them by design rather than supporting a feature the format does not need and attackers do.

Does it support Swagger 2.0?

Yes, along with OpenAPI 3.0 and 3.1. The structural differences are handled - securityDefinitions versus components.securitySchemes, host/basePath versus servers, and the two different ways uploads are expressed.

It flagged an operation as public that is actually protected.

Then the document is wrong, which is itself worth knowing - generated clients and security reviews both believe the document. Add the security requirement so the specification matches reality.

Is my document uploaded?

No. Reading and analysis both happen in your browser, and so do the exports.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.