· ReadyStack
Worked example
Real numbers from this tool, line by line.
Twenty-one findings in a 59-line OpenAPI file. That is what an API platform engineer in the EU gets back the first time they run OpenAPI Security Contract Lint on the contract their gateway already imports - eight errors, thirteen warnings, every one a line somebody wrote on purpose.
An OpenAPI document does not feel like production code. It sits in a docs folder and gets edited during a sprint nobody remembers. But it is the file the gateway imports, the file the SDK generator turns into client libraries you ship, and the file a reviewer asks for first. Whatever it declares becomes the contract, including the parts nobody meant to declare.
The fixture that ships with the extension is ordinary: two paths, three operations, the look of a spec somebody generated and then hand-edited. Here is what 18 rules find in it.
Line 6 is a server entry on http://. Every generated client takes that as the base URL, so credentials travel in the clear. Line 7 is where paths begins with no top-level security block above it - authentication has become opt-in per operation, so anything you forget ships open. Line 11 is the one that matters most: security: [] on a GET. In OpenAPI that is not a placeholder and not an omission. It states that the operation requires no authentication, and a gateway that imports the document publishes it exactly that way.
Line 25 is additionalProperties: true on a request schema - the mass-assignment route. Line 31 is an example carrying a live-looking key, and examples get copied into docs sites and SDK fixtures. Line 35 publishes a /debug path to external callers.
Then the security schemes. Line 45 declares an apiKey with in: query - that key is written into proxy access logs, browser history and Referer headers on every call. Line 49 is scheme: basic, a static credential replayed forever. Lines 53 and 56 are the two OAuth grants that RFC 9700 (BCP 240, January 2025) says clients MUST NOT use: the implicit grant, which returns the token in a URL fragment, and the resource owner password credentials grant. Line 55 is a flow with an empty scopes map - one all-or-nothing token. Two of the three declared schemes are never referenced at all.
Three operations document no 429 response, so nothing has an agreed throttling contract. One is deprecated with no sunset date named anywhere - the gap RFC 8594 exists to close.
All of it survives every free validator, because free validators ask a different question. Swagger Editor, JSON Schema tooling and Spectral's stock ruleset check whether the document is well formed. A well-formed document can say security: [] on a payments endpoint all day long. Those tools have no opinion about that line. This one names it, cites the OWASP API Security Top 10 (2023) category, and points at the row number.
The reason to care now is that the paperwork caught up. Since 11 September 2026 the EU Cyber Resilience Act's reporting clock runs: an actively exploited vulnerability in a product with digital elements sold into the EU is reported within 24 hours, a follow-up at 72 hours, a final report at 14 days. Your OpenAPI document describes the interface that gets found.
The free version audits the file open in your editor against all 18 rules and shows every finding, line number and rule reference. Nothing is withheld or counted down; that job finishes on its own. The $29 licence buys a different job: sweeping every spec in the workspace at once and writing a dated CSV, JSON or HTML report you keep next to the release. A consultant reading the same contract by hand bills $150 to $250 an hour.
The clean fixture, 63 lines, returns zero. The rules are not noise generators, and a document reviewed once passes.
Questions people ask
What does OpenAPI Security Contract Lint actually do?
It reads an OpenAPI document as text, line by line, against 18 rules taken from the OWASP API Security Top 10 (2023), RFC 9700 and RFC 8594. It reports the line number, the rule and the reason for each finding: endpoints declared with no authentication, API keys in the query string, forbidden OAuth grants, plaintext servers and undocumented rate limits.
Who is it for?
API platform and backend engineers who hand an OpenAPI file to something that acts on it: an AWS or Azure gateway that imports it, an SDK generator that ships it to customers, or a security reviewer who asks for it before a release. It is aimed at teams shipping APIs into regulated European and US markets.
Why is a free validator not enough?
Swagger Editor, JSON Schema validators and Spectral's stock ruleset check whether the document is well formed and internally consistent. A perfectly well-formed document can still say security: [] on a payments endpoint. Those tools have no opinion about that line; this one names it, cites the OWASP category, and points at the row number.
What is free and what needs a licence?
Free: audit the file open in your editor against all 18 rules, with every finding, line number and rule reference shown. Nothing is hidden or counted down. A licence adds a different job: sweeping every OpenAPI document in the workspace at once, and writing a dated CSV, JSON or HTML report you keep alongside the release.
What would this cost done by hand?
An application-security consultant reading the same contract bills roughly $150 to $250 an hour, and the OAuth grant, scope and mass-assignment questions are the slow part of that hour. A full external API penetration test is a larger engagement again. The licence is $29 once,.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. OpenAPI Security Contract Lint checks the file you open against 18 rules, each naming its legal or official basis, from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.