Restrict access to exposed API documentation

20 min Impact: medium Effort: low ✓ Scan-verified — no manual checkbox

Publicly accessible API documentation (a Swagger/OpenAPI UI, a GraphQL introspection endpoint) can reveal your entire internal API surface — every endpoint, every parameter, every data model — to anyone who finds it, even if the docs were only meant for your own development team.

Public Swagger/OpenAPI documentation maps out your entire API surface — every endpoint, every parameter. Fine if it's a public API you intend to document; a real problem if it exposes internal or admin-only routes you never meant to advertise.

The full picture

Exposed API documentation, when publicly accessible without appropriate access restriction, provides genuine, detailed insight into your application's actual internal structure and available endpoints — information that's genuinely useful for legitimate developers integrating with your API, but that also provides real reconnaissance value to anyone attempting unauthorized access or exploitation.

The specific risk here depends significantly on your actual API's genuine access model — publicly documented APIs intentionally meant for open, public use represent a different risk profile than internal or restricted APIs where documentation exposure reveals endpoints and functionality never intended for public knowledge or access.

For APIs genuinely intended to remain internal or access-restricted, exposed documentation provides an attacker with a genuine map of available endpoints, expected parameters, and potentially even example requests — significantly reducing the reconnaissance effort required compared to an attacker having to discover this same information through more difficult, active probing.

The appropriate remediation depends on honest assessment of your API's actual intended access model — genuinely public APIs may reasonably keep documentation accessible, while internal or restricted APIs warrant access-controlling this documentation the same way you'd control access to the API itself, ensuring documentation exposure doesn't undermine whatever access restrictions exist on the actual underlying functionality.

How to fix it

1

Check common documentation paths

/swagger, /api-docs, /graphql (with introspection enabled), /docs — see what's live and publicly reachable.
2

Restrict access if the API is internal-only

Put documentation behind authentication, or restrict it to specific IPs, if the API itself isn't meant for public/partner use.
3

Disable GraphQL introspection in production specifically

Introspection is genuinely useful in development but should typically be off in your production environment.
4

If the API is intentionally public, this is fine

Public APIs with public docs (a documented partner API) don't need this fixed — the check exists to catch INTERNAL docs left open by accident.

Common mistakes

This isn't always a problem — if you run a genuinely public API with intentionally public documentation, leave it. This matters specifically for internal-only APIs exposed by accident.

How you'll know it's done

API documentation is either intentionally public, or properly restricted behind authentication.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →