What are the most common nginx security mistakes?

Leaving old TLS versions (TLSv1, TLSv1.1) enabled; not setting security headers like HSTS and X-Frame-Options; leaving server_tokens on so the nginx version is advertised; no client_max_body_size so a large upload can exhaust resources; and add_header used inside a location without always, which silently drops the header on error responses. None of these break the site, so they sit there until a security review or an incident finds them.

Why does add_header need always?

By default nginx only applies add_header to a limited set of successful response codes. So a security header you set without the always flag is missing on error responses (4xx, 5xx) - exactly the responses an attacker probing your site sees most. Adding always ensures the header is sent on every response, which is almost always what you intend for security headers like HSTS.

Is it safe to paste my nginx config?

Yes. The checker runs entirely in your browser - nothing you paste is uploaded or logged. nginx configs are not usually secret, but they can contain internal hostnames or paths, and either way they never leave your machine here.

Free tool · Runs in your browser · Nothing uploaded

Check your nginx config.

nginx will serve happily with old TLS, no security headers, and its version on display. Paste your config and get a security review — weak TLS, missing headers, version disclosure, no rate limiting, directory listing — each with the fix.

100% client-side

Serving fine, quietly insecure

An nginx config is one of those things you set up once and never look at again — which is exactly why the weak defaults persist. Old TLS that a scanner flags, a missing HSTS header, the version banner advertising what to attack, an unbounded request body that lets one upload chew through resources. None of it stops the site working; all of it shows up in a security review or, worse, in an incident. A two-minute read now is cheaper than either.

Getting the config right once is the easy part. Knowing it stays right across every server and every change, and being alerted when a header you set quietly disappears, is the ongoing job a control plane handles across the infrastructure you own.

Related free tools

UFW firewall generatorLock down your server SSH hardening generatorLock down sshd_config fail2ban config generatorAuto-ban brute-forcers nginx rate limit generatorCap abuse + brute force

All free tools →

Right once, and kept that way.

Infraveil manages your edge config and watches for drift across every host you own — so the TLS, headers, and limits you set stay set, with a tamper-evident record proving it. Generate a hardened config with our proxy and headers tools, then keep it honest.

See how it works

Get the edge-hardening playbook

nginx, TLS, headers, and proxy hardening for a backend you run yourself. No spam.