NGINX Config Security Audit Prompt
Audit an NGINX config for the classic misconfigurations — version leakage, missing security headers, open proxy, path traversal, exposed dotfiles — and get a prioritized fix list with exact directives, not a generic checklist.
- Target user
- Engineers and security reviewers hardening an existing NGINX deployment
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior application-security engineer doing an NGINX config review. You find real misconfigurations — open proxies, path traversal, leaked internals — and you rank them by exploitability, citing the exact line that's wrong.
I will provide:
- The full NGINX config (server/location/http blocks): [PASTE NGINX CONFIG]
- What's public vs internal, and any admin/internal paths: [DESCRIBE EXPOSURE]
- The backend(s) being proxied: [DESCRIBE BACKEND]
Audit for, at minimum:
1. **Information leakage** — `server_tokens off`, removing/overriding `Server` and backend-revealing headers, hiding version banners and error-page internals.
2. **Security headers** — presence and correctness of `X-Content-Type-Options`, `X-Frame-Options`/CSP frame-ancestors, `Referrer-Policy`, and HSTS; note `add_header` inheritance (a header set in a child `location` drops parent headers).
3. **Open / SSRF-prone proxy** — `proxy_pass` to a variable or client-controlled host, missing `internal;` on `X-Accel-Redirect` locations, and `resolver`-driven dynamic upstreams that allow request smuggling to arbitrary hosts.
4. **Path traversal & alias bugs** — the classic `location /foo { alias /bar/; }` missing trailing-slash traversal, `..%2f` handling, and `try_files`/`root` mistakes that serve files outside the intended dir.
5. **Exposed sensitive paths** — `.git`, `.env`, `.htpasswd`, dotfiles, backups; deny rules for these.
6. **Request limits & methods** — `client_max_body_size`, `limit_except` to restrict methods, and `if`-block misuse (`if is evil`).
7. **TLS posture** — a quick check that TLS isn't obviously weak (defer deep TLS work to a dedicated pass).
Output: (a) a findings table ranked by severity with the offending line quoted and a one-line impact, (b) a corrected config snippet per finding, (c) the `nginx -t` + curl checks to confirm each fix (e.g. `curl -I` for headers, a traversal probe for the alias bug). Apply fixes after `nginx -t` and reload; never hot-edit the live config, and back it up first.
Why this prompt works
NGINX security bugs cluster around a handful of well-known footguns — the alias trailing-slash traversal, add_header inheritance silently dropping headers in child locations, and proxy_pass to a variable opening an SSRF path. A generic “harden your config” pass misses these because they look fine in isolation. The prompt enumerates each specific class so the audit checks for the bugs that actually get exploited.
Ranking findings by exploitability with the offending line quoted turns the output into a triage queue, not a wall of equal-weight suggestions. You fix the open proxy before you fix a missing Referrer-Policy, because the prompt forces an impact statement on each.
Every finding ships with a concrete verification — curl -I for the header drop, a ..-style probe for the alias traversal — so you prove each fix rather than assume it. Combined with the nginx -t, backup, and reload guardrail, the audit stays a reviewable, human-controlled process instead of a blind rewrite of a live config.