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 (Apache-2.0), self-hostable
Findings are currently reported in German; an English report is in preparation.
0 KB VON 2 048 KB
Spezifikation hier einfügen oder eine Datei auf das Formular ziehen. Es wird kein einziger Request an Ihre API gesendet.
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 ist Open Source (Apache-2.0); wer nichts hochladen darf, betreibt ihn intern.
Three states
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.
1Documented
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.
2Likely
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.
3Runtime only
Twelve risk classes no document can show: token signatures, CORS, security headers, rate limits. They are named and counted — never graded.
What the check sees
About 30 rules, deliberately no more.
Missing or weak authenticationOperations without a security requirement, Basic Auth, OAuth2 Implicit Flow, API keys in the query string.
OR instead of ANDSeveral alternative security schemes on one operation — behind API gateways the most common cause of auth bypasses, and directly readable.
Sensitive data in responsesFinancial, 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 issuesSeveral API versions side by side, deprecated without sunset, server URLs on staging or localhost, plaintext transport.
Resources and schemasLists without pagination, uploads without size limits, schemas without length constraints — reported as aggregates, not as noise per endpoint.
What it cannot see
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 verifiedThe 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’ objectsObject-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 truthA schema with additionalProperties: false is a promise. Whether the backend keeps it is a different question.
What is not documented at allSwagger UI, debug routes, old versions without an entry. What is not in the document, no document can show.
Context
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.
FAQ
Frequently asked questions
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 is open source (github.com/cehlert9999/sectestx-api-scanner) — you can read it, or run it on your own infrastructure.
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.
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.
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.
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 wm-audit, a separate tool that runs locally — an export contains credentials and does not belong on any website. More at leanofy.de/wm-audit.
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.
sectestx
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.
