Skip to content

Knowledgebase

Configuring trusted proxy headers for Flask

development

When a reverse proxy terminates HTTPS or changes the request path, Flask may otherwise see an internal scheme, host or client address. Proxy middleware must match the actual trusted proxy chain.

Check access and requirements

Ask for the supported proxy configuration if you do not control the server. Identify which headers are set or replaced and whether clients can reach the application directly.

01 Configure trusted proxy headers for Flask

  1. Inspect the incorrect behavior, such as generated HTTP links, redirect loops or a wrong client address. Record the public request and the internal deployment path.

  2. Use Werkzeug ProxyFix only when the application is actually behind the relevant trusted proxy. Configure the number of trusted values separately for each forwarded header type.

  3. Ensure the edge proxy removes untrusted incoming values or otherwise establishes a reliable chain. Do not assume every header containing a public-looking address is trustworthy.

  4. Configure the application’s allowed hosts and secure cookie behavior for the final public origin. Keep proxy trust and hostname validation as distinct controls.

  5. Restart the application and test redirects and URL generation from outside the hosting network.

02 Example: trust only the forwarded values your proxy supplies

Use this Flask pattern only for a verified deployment with one trusted proxy that replaces X-Forwarded-For and X-Forwarded-Proto, and where visitors cannot reach the upstream directly. Other topologies require different, explicitly reviewed counts.

Code or configuration example
from werkzeug.middleware.proxy_fix import ProxyFix

app.wsgi_app = ProxyFix(
    app.wsgi_app,
    x_for=1,
    x_proto=1,
    x_host=0,
    x_port=0,
    x_prefix=0,
)

This example intentionally does not trust forwarded host, port or prefix values. Configure the canonical host and cookie settings separately. In staging, submit a harmless forged forwarded header through the public edge and confirm the proxy overwrites it instead of allowing the client to choose the application’s scheme or client identity.

Expected result: Generated HTTPS links and client-address handling match the real request path. The correction resolves the observed proxy symptom without trusting every incoming header.

Confirm the expected result

Verify HTTPS links, the canonical hostname and expected client address. In a controlled test, confirm a forged forwarded header cannot override trusted request information.

Resolve setup problems

A mismatch in proxy counts can trust a client-provided value or ignore a legitimate proxy. Correct the topology information instead of setting every trust count to a large number.

A common question

Should ProxyFix be enabled on every Flask application?

No. It is needed only for an appropriate proxy deployment. Enabling it without understanding the incoming headers can make application decisions depend on untrusted data.

Sources and further reading

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support