Skip to content

Knowledgebase

Protecting FastAPI documentation and health endpoints

development

Interactive API documentation and health routes are separate from the authorization rules on business endpoints. Decide deliberately which interfaces should be public in production.

What you need before you begin

List the documentation, OpenAPI schema, metrics and health URLs exposed by the app and proxy. Identify what information each response contains.

01 Protect FastAPI documentation and health endpoints

  1. Configure documentation and schema URLs according to the application’s audience. Disable them or put them behind an appropriate authenticated route when they contain non-public integration details.

  2. Keep authentication and permissions on the real API endpoints. Hiding documentation does not prevent a caller from sending requests to a known route.

  3. Create a minimal health response with a suitable status code. Keep secret values, full configuration and detailed exception traces in private diagnostics.

  4. Separate lightweight availability checks from deeper dependency checks. Use timeouts and avoid expensive database work on every frequent health request.

  5. Test access as an anonymous visitor, an authorised API user and the monitoring service through the public proxy.

02 Example: disable default FastAPI documentation routes

When the production API should not publish interactive documentation or its schema, configure that policy where the existing FastAPI application is constructed.

Code or configuration example
from fastapi import FastAPI

app = FastAPI(
    docs_url=None,
    redoc_url=None,
    openapi_url=None,
)

Merge these options into your actual constructor, preserving middleware and routes. This disables the default documentation and schema endpoints; it does not authorize or hide the business API itself. Keep every required authentication and resource-ownership check.

Expected result: direct anonymous requests to the former documentation and schema URLs no longer return those resources. Test a protected business route separately and verify that an unauthorized request still fails. A minimal monitoring endpoint can remain available according to its own access policy without exposing detailed configuration.

Confirm the expected result

Confirm each role sees only the intended information and that disabled documentation URLs no longer return the schema. Verify the monitor can detect a controlled application failure.

Troubleshoot unexpected results

A route protected only in the proxy may remain reachable through a publicly exposed upstream port. Check network exposure as well as application routing.

A common question

Does disabling Swagger UI secure my API?

It reduces one discovery interface, but authentication, authorization, validation and deployment controls still protect the actual API. Test those controls directly.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support