Nginx Config Analyzer: Grade and Harden Your nginx.conf

1. On your server, print the fully assembled config: sudo nginx -T. That resolves every include, which cat /etc/nginx/nginx.conf does not.
2. Paste the output above. The review runs as you type, in your browser, and nothing is uploaded.
3. Read the findings worst-first. Each one shows the directive, the line, the block it lives in, and what it should be.
4. Open the Header map tab. It shows, per location, which security headers actually apply and which were silently dropped. This is the part a config review by eye almost always misses.
5. Switch to the Hardening patch tab. Apply the safe lines first, stage the rest one at a time, then run sudo nginx -t and sudo systemctl reload nginx.

This is the single most common way a hardened-looking nginx config is not hardened. The documentation states it plainly: add_header directives are inherited from the previous configuration level if and only if there are no add_header directives defined on the current level.

It is all or nothing. Set HSTS, CSP, X-Frame-Options and X-Content-Type-Options at server level, then add one unrelated header inside a location, and all four stop applying to that location. Not the one you added. All of them.

The config still reads as though the headers apply everywhere. nginx prints no warning, nginx -t is happy, and the only way to notice is to request a URL inside that location and read the response headers. A header scanner pointed at your homepage will report a clean bill of health while /api serves nothing at all.

The fix is to re-declare the full set inside every block that adds a header of its own, or to put them in one file and include it in both places. There is no merge option. The Header map tab shows you exactly which blocks are affected.

A prefix location matches anything that starts with the prefix, then nginx strips it and appends whatever is left to the alias. When the location has no trailing slash and the alias does, those two facts combine into a directory traversal:

location /files with alias /var/www/files/; means a request for /files../secrets.env resolves to /var/www/secrets.env. The location looks scoped to one directory. It is not.

The same off-by-slash affects proxy_passwhen the target has a URI part, which lets a request reach backend paths the location was supposed to hide. Both were popularised by Orange Tsai's "Breaking Parser Logic" research and both are still common.

Fix it by matching the slashes on both sides, or by using root, which appends the full URI and does not have this failure mode.

By default add_header only applies to a fixed list of response codes: 200, 201, 204, 206, 301, 302, 303, 304, 307 and 308. Anything else, including every 4xx and 5xx, gets no header at all.

So a 404 page, a 500 from a crashed upstream, or a 403 from an access rule is served with no CSP, no X-Frame-Options and no HSTS. Error pages are also the most likely place for a template to reflect part of the request back to the user, which is exactly when a CSP matters.

The always parameter removes the response-code restriction. Every security header you set should have it. In the Header map tab, a header marked with an asterisk is one that is missing it.

This tool reads text, and it is honest about the limits of that. It cannot tell you whether your certificate expires next week, what your server actually sends back, whether a stray .env is sitting in the web root, whether nginx itself needs patching, or what flags your application sets on its cookies. None of that is in the config.

Those checks need the running machine. The web server fix library documents all 36 of them, including the ones this tool covers, and CtrlOps runs the whole set over SSH across every server you manage.

Building a new config rather than reviewing one? The Nginx Config Generator writes a server block with these defaults already correct. For the SSH side of the same server, the sshd_config Analyzer does the equivalent review.