API security scan — OpenAPI, GraphQL and access checks SecQon runs from outside

Most APIs describe themselves in an OpenAPI (Swagger) document or a GraphQL schema. SecQon looks for that contract and asks one question of it: what can an anonymous outsider reach that the schema says should need authentication? The check is read-only by construction — it can only send GET requests, never calls a write operation, and stops at 26 requests. It runs on Standard and Deep scans, and the penetration-test tier (Business, or the one-off pentest report) adds two object- and account-level API tests.

Runs on: Standard and Deep scans, on every plan (Free can launch Standard manually). The IDOR/BOLA and mass-assignment tests run only on Deep + pentest, which is Business or the one-off pentest report.
Included from: Free plan ($0)
OWASP Top 10 (2021): A01 A05 A08

What we test

Finds your API contract
Looks for a JSON schema at five standard locations (such as /openapi.json, /swagger.json and /v3/api-docs), under your base path and at the root, plus up to three schema URLs found by the crawl on Deep scans.
Operations that answer without their declared authentication
Calls secured, read-only operations that take no parameters without credentials. If one answers anyway, that is reported as high.
Publicly readable schema
Reports, for information, when an anonymous visitor can read a schema that lists your authenticated operations.
GraphQL introspection
One introspection query to /graphql, sent over GET. Reports introspection left enabled (medium).
Credentialed CORS
Reports an API endpoint that reflects any origin and also allows credentials, which lets another website read logged-in responses (high).
Stack traces in responses
Reports framework stack traces found in responses we already fetched (medium).
Control request first
Every run starts with a path that cannot exist, and responses identical to it are ignored — so a single-page app that answers every URL does not produce false findings.
IDOR/BOLA precondition (Business pentest tier)
Checks whether sequential object IDs return different objects while an impossible ID returns a clean 404. Reported as unconfirmed, because proving it needs a second account.
Mass assignment (Business pentest tier)
With stored credentials, updates the tester’s own account through a self-update endpoint such as /me with clearly marked probe values, then reads them back. Reported as unconfirmed.

Why it matters

APIs are where the data is. A web page shows a user what the interface chooses to show; the API behind it returns whatever the server decides that caller is allowed to have. The most common serious API flaw is not exotic — it is an endpoint that forgot to check who is asking. If your own schema says an operation needs authentication and it answers an anonymous request anyway, that is a data exposure waiting to be found.

The schema itself is a map. A public Swagger file or GraphQL introspection tells an attacker every operation, parameter and type you have, which saves them most of the work of reconnaissance. Sometimes that is intended — a public API — and sometimes it was left on from development. Credentialed CORS and leaked stack traces are similar: small configuration choices that hand an outsider more than they should have.

Because this check works from your own contract rather than guessing URLs, it stays small and predictable. It reads what you have already published, asks a bounded number of questions, and never changes data.

An example finding, and its fix

A finding of a type this check really produces. The evidence is illustrative, not taken from a customer's scan.

Medium

GraphQL introspection is enabled

Evidence

GET https://api.example.com/graphql?query={__schema{types{name}}} → 200 OK
content-type: application/json
{"data":{"__schema":{"types":[{"name":"Query"},{"name":"User"},{"name":"Invoice"}, …

How to fix it

Decide whether your GraphQL API is meant to be public. If it is not, disable introspection in production. In most servers this is one setting — for example, introspection: false in the server options, enabled only in development. If clients need the schema, publish it to them through your documentation or build tooling instead. Re-test the finding from your report.

What we don't test

YAML schemas. Only JSON OpenAPI and Swagger documents are read.
GraphQL over POST. Introspection is tested over GET only, so a server that accepts GraphQL only by POST cannot be tested.
Endpoint brute forcing. We never guess API paths; we test what your schema declares.
Write operations. Schema write operations are counted but never called (the one exception is the mass-assignment test on the tester’s own account, on the pentest tier).
Confirmed IDOR/BOLA. We report the precondition as unconfirmed; confirming it needs a second test account.
Business logic and race conditions, which no automated external test can judge.

Every report names what its scan did and did not assess. See the full OWASP Top 10 coverage, including the two categories no external scan can assess.

API security: questions people ask

Does the API check change or delete any data?

No. On Standard and Deep it can only send GET requests — write operations in your schema are counted, never called. The only exception is the mass-assignment test on the Business pentest tier, which updates the test account’s own record with clearly marked values.

Do I need an OpenAPI or Swagger file for this to work?

The operation-level tests need one, in JSON. Without a schema, the GraphQL introspection and stack-trace checks still run, and credentialed CORS is covered by the exposed-files and CORS check on the same scan.

Does SecQon test for IDOR or BOLA?

On the Business pentest tier it tests the precondition — whether sequential object IDs return different objects — and reports it as unconfirmed. Confirming that one user can read another’s data needs a second account, and the finding says so.

Will the scanner send requests to hosts listed in my schema?

No. Server URLs inside the schema are ignored; requests only ever go to the host you verified.

Is it safe to run the API check on a production API?

Yes. It is capped at 26 requests, uses read-only calls without parameters, and every request passes the same per-asset rate limit as the rest of the scan.

Other checks

TLS & certificates
Certificate trust and expiry, and whether your server still accepts TLS 1.0 or 1.1.
Security headers & cookies
Missing or ineffective HSTS, CSP, clickjacking, nosniff and Referrer-Policy headers, plus cookie flags.
DNS & email security
SPF, DMARC, CAA and DNSSEC — the records that stop spoofed email and mis-issued certificates.
Exposed ports & services
36 high-risk TCP ports — databases, container control planes, remote admin — checked with one connect each.
Web application pentest
A browser-rendered crawl plus bounded proofs for XSS, SQL injection and SSRF, and an active scanner on the pentest tier.

Last reviewed against our scanning documentation on 24 Sep 2026.

See what a scan finds on your own asset

Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.

Start free Compare plans

API security scan — OpenAPI, GraphQL and access checks SecQon runs from outside

What we test

Finds your API contract

Operations that answer without their declared authentication

Publicly readable schema

GraphQL introspection

Credentialed CORS

Stack traces in responses

Control request first

IDOR/BOLA precondition (Business pentest tier)

Mass assignment (Business pentest tier)