🌐 Reviewing nginx Security Configuration with AI

nginx sits at the edge of almost everything I run, which means its config is the most externally-exposed security boundary I own. And nginx config is deceptively easy to get subtly wrong: a trailing slash in the wrong place turns a proxy_pass into a path-traversal bug, an alias directive becomes a way to read files outside the web root, and a default TLS config happily negotiates ciphers that were broken a decade ago.

I’ve audited a lot of these configs, and the same handful of mistakes show up again and again. The directives are well-documented but the interactions are tricky, which makes this ideal work for an AI first pass — defensive review to find the exposure before someone on the internet does. Here’s how I run it.

The recurring nginx security mistakes

Most edge exposure comes from a short list:

• Weak TLS — old protocol versions (TLSv1, TLSv1.1) or weak cipher suites still enabled.
• Version disclosure — server_tokens on leaking the exact nginx version in every response and error page.
• Missing security headers — no HSTS, no X-Content-Type-Options, no frame protection.
• alias and location traversal — a misplaced trailing slash letting .. escape the intended directory.
• Over-permissive proxying — proxy_pass configs that forward more than intended, or trust client-supplied headers like X-Forwarded-For without sanitizing.

Each is a one-or-two-line issue, but spotting them means understanding nginx’s matching and normalization rules, which is precisely where a careful reviewer earns its keep.

Collect the full config, includes and all

nginx configs are split across files via include, so audit the assembled whole, not one server block:

# Validate syntax and confirm which files are in play
sudo nginx -t

# Dump the fully-assembled config nginx actually loads
sudo nginx -T > /tmp/nginx-full.conf 2>/dev/null

# Quick spot-checks before the deeper review
grep -rn "server_tokens\|ssl_protocols\|ssl_ciphers\|alias\|proxy_pass" \
  /etc/nginx/

The nginx -T dump is the one to feed the model — it’s the flattened, effective config including every include, which is what’s actually serving traffic.

A targeted nginx security review prompt

I scope the prompt to edge-security concerns and ask for an ordered risk list:

You are a web-server security reviewer auditing an nginx config. Find
security issues ONLY, ranked by severity:
1. TLS: any protocol version below TLSv1.2 enabled, or weak/legacy
   cipher suites. Recommend modern equivalents.
2. Information disclosure: server_tokens, leaked backend versions,
   verbose error pages exposed to clients.
3. Missing security response headers (HSTS, X-Content-Type-Options,
   X-Frame-Options / frame-ancestors, Referrer-Policy).
4. Path traversal risk in alias/location blocks (trailing-slash
   mismatches, root vs alias confusion).
5. Proxy issues: trusting unsanitized client headers, over-broad
   proxy_pass, request smuggling exposure.
Explain each finding's real-world impact. Do not rewrite the file.

<paste nginx -T output>

The path-traversal check is the one humans miss most. A good review catches the classic alias footgun:

# DANGEROUS: missing trailing slash on alias allows ../ traversal
location /static {
    alias /var/www/assets/;
}

# SAFE: matching trailing slashes confine requests to the directory
location /static/ {
    alias /var/www/assets/;
}

Pro Tip: Ask the model specifically to “check every alias and location for trailing-slash mismatches between the location path and the alias path.” This single class of bug is responsible for a surprising number of file-disclosure vulnerabilities, and it’s nearly invisible to a casual read because both versions look almost identical.

Harden TLS and headers concretely

Once the gaps are confirmed, the fixes are standard. Modern TLS and a clean header block:

# Modern TLS only
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;   # let clients pick from a modern list

# Don't advertise your version
server_tokens off;

# Baseline security headers
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;

The model will recommend cipher strings, but I never paste a model-suggested ssl_ciphers line into production without checking it against current Mozilla SSL Configuration Generator guidance — cipher recommendations age, and a hallucinated cipher name will simply fail to load. Always run nginx -t before reloading.

Keep the front door under continuous review

Edge config changes constantly as new routes and services get added, and each change can reopen an old hole. I run this audit on every nginx config change, the same way our code review dashboard flags risky diffs in general. This pairs well with broader edge-protection work in WAF and rate limiting and certificate lifecycle management. For the review I drive Claude or work directly in Cursor against the config file.

Defensive, human-verified, no secrets

The model is a fast junior reviewer that has the whole catalog of nginx footguns memorized and never gets bored reading server blocks. But it can hallucinate a cipher name, misjudge whether a header is right for your app, and miss app-specific context. So every TLS and header change gets validated with nginx -t and tested before reload, and I confirm cipher recommendations against an authoritative source. I redact anything sensitive — upstream IPs, internal hostnames, any embedded auth_basic credentials or secrets — before the config leaves my terminal. The structure is all the model needs.

Conclusion

Your reverse proxy is the most exposed config you own, and its mistakes are subtle by nature. An AI reviewer makes a thorough edge audit fast and repeatable — TLS, disclosure, headers, traversal, proxying — while you stay the human who validates the cipher list, runs nginx -t, and owns the reload. Fold it into your broader security and hardening routine with a reusable prompt library.