Check API security — without touching the API.
Paste your OpenAPI or Swagger specification and get two grades right away, every documented finding with its location in the file, the test cases a live run would need, and an honest list of what a document cannot show. No sign-up, and not a single request to your API.
- No request to your API
- Nothing is stored
- No sign-up, no email
- Open source release planned, self-hostable
Findings are currently reported in German; an English report is in preparation.
Ihre Spezifikation wird ausschließlich im Arbeitsspeicher verarbeitet und nie gespeichert. Es wird kein einziger Request an Ihre API gesendet. Im Bericht erscheinen nur Feldnamen, nie Beispielwerte. Der Dienst wird als Open Source veröffentlicht; wer nichts hochladen darf, betreibt ihn dann intern.
A finding from a document is not a measurement.
So every finding says how solid it is — and never claims more than the document supports.
Documented
Directly readable from the specification, with a JSON pointer to the location. Only these findings affect the grades — a write operation without a security requirement, or IBAN fields in an unauthenticated response.
Likely
Strong indications in the document, but not decidable. They become the list of what a live test would need to check: object-level authorization, role enforcement, mass assignment.
Runtime only
Twelve risk classes no document can show: token signatures, CORS, security headers, rate limits. They are named and counted — never graded.
About 30 rules, deliberately no more.
Missing or weak authentication
Operations without a security requirement, Basic Auth, OAuth2 Implicit Flow, API keys in the query string.
OR instead of AND
Several alternative security schemes on one operation — behind API gateways the most common cause of auth bypasses, and directly readable.
Sensitive data in responses
Financial, identity and credential fields in response schemas, detected by field name. Example values are never read.
Admin and diagnostic paths
/admin, /internal, /actuator, /debug — documented, but without a role or without any authentication.
Inventory issues
Several API versions side by side, deprecated without sunset, server URLs on staging or localhost, plaintext transport.
Resources and schemas
Lists without pagination, uploads without size limits, schemas without length constraints — reported as aggregates, not as noise per endpoint.
And what it says so about.
A good grade means the specification is ready for testing — not that the API is secure. Against a reference API with 22 documented vulnerabilities, 12 are visible statically. The other 10 are listed in the report by name.
Whether a token is really verified
The specification says “bearer”, not what happens behind it. Whether an alg:none token is accepted only shows in a request.
Whether a user can reach other users’ objects
Object-level authorization lives in the backend and needs two identities. The most common API vulnerability is invisible to static analysis by design.
Whether the document tells the truth
A schema with additionalProperties: false is a promise. Whether the backend keeps it is a different question.
What is not documented at all
Swagger UI, debug routes, old versions without an entry. What is not in the document, no document can show.
A documented test approach — not a certificate of conformity.
Each finding carries its OWASP API Security Top 10 (2023) mapping, and the test cases state the expected behaviour. That supports the documentation duties many organisations have under ISO/IEC 27001 (control 8.29, security testing in development and acceptance) and, in Germany, § 30 (2) no. 5 BSIG.
The check replaces neither a penetration test nor an audit and does not establish conformity with NIS2, DORA or any other framework. It is a static analysis of a document — nothing more, and nothing less.
Frequently asked questions
Is my specification stored?
No. It is processed in the server’s memory only, the result is returned signed to your browser, and afterwards nothing remains. There is no access log; IP addresses are kept only as a daily rotating hash for rate limiting. The service will be released as open source — you can then read it, or run it on your own infrastructure.
Does the check send requests to my API?
No, not a single one. The service has no function to fetch URLs, and an isolation test in the source code prevents one from ever being added. Everything in the report follows from the document.
Why letter grades and not a percentage?
Because a heuristic judgement from a document must not claim percentage-point precision. Two grades — security design and specification hygiene — stay separate so that clean schemas cannot average out missing authentication. Every cap is explained in the report.
Which formats are supported?
OpenAPI 3.0 and 3.1 and Swagger 2.0 as JSON or YAML, up to 2 MB. OpenAPI 3.2 constructs such as additionalOperations or the QUERY method are not evaluated but are listed by name as blind spots — the check never reports “checked” for something it did not read.
What if my API runs behind webMethods API Gateway?
The check recognises typical traits and points out that the effective policies are not in the specification but in the gateway export. For the export there is a separate tool that runs locally — an export contains credentials and does not belong on any website.
How is this different from the full sectestx?
The check says what should be tested. sectestx tests it: from the same specification it generates executable OWASP tests that run inside your own network and produce evidence per finding — for the twelve risk classes a document cannot show.
That was the specification. The rest is runtime.
sectestx turns your specification into executable security tests, runs them inside your own network and backs every finding with evidence. For teams that want more than a list of what to test.