Nginx Security Configuration: Complete Hardening Guide

Before you start, run a free ZeriFlow scan to get a baseline. After applying these changes, scan again to confirm every improvement registered.

Hiding Server Information With server_tokens off

The first thing any attacker does is fingerprint your server. By default, Nginx includes its version number in HTTP response headers (Server: nginx/1.24.0) and in error pages. This tells attackers exactly which CVEs to try.

Add this to your http {} block in /etc/nginx/nginx.conf:

This removes the version number from the Server header (the header itself remains as Server: nginx, which is unavoidable without a paid module, but the version is gone). It also removes the version from default error pages.

For complete header removal, consider the nginx_more_headers module or a commercial Nginx Plus subscription, but server_tokens off is the essential first step that every server should have.

Verify:

You should see Server: nginx with no version number.

Enforcing TLS 1.3 and Disabling Legacy Protocols

TLS 1.0 and 1.1 are deprecated and vulnerable to BEAST, POODLE, and CRIME attacks. TLS 1.2 is still acceptable but TLS 1.3 is significantly faster (1-RTT handshake) and more secure (forward secrecy by default).

Key decisions explained: - ssl_prefer_server_ciphers off: Modern clients select the best cipher they support. Letting the client choose is now the recommended approach. - ssl_session_tickets off: Session tickets can leak session data if your ticket keys are compromised. Disabling them improves forward secrecy. - ssl_stapling on: OCSP stapling caches the certificate revocation status, eliminating a round trip to the CA and improving performance.

Security Headers: The Essential Set

Security headers tell browsers how to behave when rendering your content. Without them, browsers default to permissive behavior that enables XSS, clickjacking, and MIME sniffing attacks.

Add these to your server {} block:

What each header does: - X-Frame-Options: DENY: Prevents your site from being embedded in iframes on other domains (clickjacking protection). - X-Content-Type-Options: nosniff: Prevents browsers from MIME-sniffing responses away from the declared content type. - Strict-Transport-Security: Forces HTTPS for the specified duration, even if the user types HTTP. - Content-Security-Policy: Whitelists the sources from which resources can be loaded. This is the most powerful and most complex header — tune the script-src directive carefully for your specific application.

Important: The CSP above uses 'unsafe-inline' for scripts as a starting point. For maximum security, replace this with nonces or hashes for inline scripts. The always keyword ensures headers are sent even on error responses.

Rate Limiting: Stopping Brute Force and DDoS

Nginx's limit_req module allows you to throttle requests per IP address, which is essential for protecting login endpoints, APIs, and form submissions.

Parameters explained: - burst=20: Allows a burst of up to 20 requests before rate limiting kicks in. - nodelay: Processes burst requests immediately rather than queuing them, reducing latency for legitimate users. - 10m memory: Stores state for approximately 160,000 IP addresses per 10MB. Size accordingly for your traffic.

When a client exceeds the rate limit, Nginx returns a 429 (Too Many Requests) status. You can customize this with limit_req_status 429; and a custom error page.

Blocking Common Attack Patterns

Beyond rate limiting, you can use Nginx's map and if directives to block known malicious patterns:

Verifying With ZeriFlow

After applying these configuration changes, reload Nginx with nginx -t && systemctl reload nginx and then run a ZeriFlow scan to verify: - All security headers are present and correctly formatted - TLS configuration passes modern security standards - No server version disclosure in response headers - HTTP to HTTPS redirect is working correctly - HSTS header is present with a sufficient max-age

ZeriFlow's 80+ checks will catch edge cases like headers missing from error responses, incorrect CSP syntax, or certificate chain issues that are easy to miss in manual testing.

FAQ

### Q: Can I put security headers in nginx.conf instead of individual server blocks? A: Yes — place add_header directives in the http {} block for site-wide application. However, note that Nginx's inheritance model means if a server {} or location {} block defines any add_header directive, it overrides all headers from the parent block. Use a separate include file to avoid this pitfall.

### Q: What TLS ciphers should I disable completely? A: Never allow RC4, DES, 3DES, or NULL ciphers. Avoid MD5 and SHA-1 in cipher names. The Mozilla SSL Configuration Generator (ssl-config.mozilla.org) produces a regularly updated cipher list — use the 'Intermediate' profile for the best balance of compatibility and security.

### Q: Does rate limiting affect crawlers like Googlebot? A: Rate limiting applies to all IP addresses equally. Googlebot typically crawls at a moderate, respectful pace that stays well under sensible rate limits. If you have concerns, you can exclude Googlebot's verified IP ranges from rate limiting using a geo block.

### Q: Should I use HTTP/2 or HTTP/3? A: Enable HTTP/2 by adding http2 to your listen directive (listen 443 ssl http2). HTTP/3 requires the QUIC module, which is not in standard Nginx builds yet but is available in Nginx Plus and some distributions. HTTP/2 alone provides significant performance benefits over HTTP/1.1.

### Q: How do I test my CSP without breaking my site? A: Use Content-Security-Policy-Report-Only instead of Content-Security-Policy during testing. This sends the same header but only reports violations to a specified endpoint rather than blocking them. Once you have zero violations in your logs, switch to enforcement mode.

Conclusion

Nginx security configuration is a multi-layered discipline. No single directive makes your server secure — it is the combination of version disclosure prevention, strong TLS, security headers, rate limiting, and attack pattern blocking that creates genuine defense in depth.

Apply these changes systematically, test after each change, and document your configuration in version control so you can reproduce it when you provision new servers.

Scan your Nginx server with ZeriFlow to get a comprehensive security report in under 60 seconds. The free scan covers all 80+ checks and gives you a prioritized remediation list specific to your server's current configuration.

Further Reading

• RFC 6797 — HTTP Strict Transport Security (HSTS)
• Mozilla SSL Configuration Generator
• RFC 8996 — Deprecating TLS 1.0 and TLS 1.1

<!-- zf-internal-links -->