how to harden an Nginx reverse proxy

TL;DR

A hardened Nginx reverse proxy runs current TLS only, sends security headers on every response, limits request sizes and rates, and hides version banners. Apply the config, test with curl and a header checker, and keep the baseline in version control. Most proxy hardening is a one-time config pass plus periodic review.

The query

how to harden an Nginx reverse proxy

Use this when

• Nginx fronts your apps and you want a defensive baseline in one pass
• A scan flagged missing security headers or weak TLS on the proxy
• You are writing a standard reverse-proxy config for your org
• You need rate limiting and body-size limits to blunt abusive traffic

Not for

• Hardening Nginx as an origin web server; some advice differs there
• WAF rule authoring; that is a separate layer in front of or behind the proxy
• Fixing upstream app bugs; the proxy can only protect the edges

Steps

1. Run a current Nginx and hide the version. Keep Nginx patched and set server_tokens off; so responses do not advertise the version. Expected output: response headers show no Nginx version string.
2. Lock down TLS. Allow only TLS 1.2 and 1.3, use a strong cipher list, and enable HSTS with preload intent once you are ready to commit. Expected output: a TLS scan shows no weak protocols or ciphers.
3. Add the security headers. Set X-Content-Type-Options, X-Frame-Options (or frame-ancestors in CSP), Referrer-Policy, and a Content-Security-Policy that fits your apps. Expected output: every response carries the header set, verified with curl.
4. Limit request size and rate. Set clientmaxbody_size to what your apps actually need and add rate limiting on login and API endpoints. Expected output: oversized requests are rejected, and rapid-fire requests get 429s.
5. Restrict what the proxy exposes. Do not proxy admin paths to the internet, block dotfiles and backup extensions at the proxy, and log access for review. Expected output: requests for admin and dotfile paths return 404 or 403 at the proxy.
6. Test and version the config. Run a header and TLS check after every change and keep the config in git. Expected output: checks stay green across deploys, config changes are reviewable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YlmrdHsPQJbcPD6vE2tC-w

Resolved from the public thread: https://vectle.com/posts/pst_YlmrdHsPQJbcPD6vE2tC-w

Thread query: how to harden an Nginx reverse proxy

TL;DR: A hardened Nginx reverse proxy runs current TLS only, sends security headers on every response, limits request sizes and rates, and hides version banners. Apply the config, test with curl and a header checker, and keep the baseline in version control. Most proxy hardening is a one-time config pass plus periodic review.