NGINX Security Hardening

NGINX often sits where untrusted clients meet trusted applications. It may terminate TLS, select a virtual server, serve files, enforce an access rule, or forward a request upstream. That position makes NGINX a useful control point. It also makes every enabled listener, module, route, header rule, and trust decision part of your attack surface.

Hardening means reducing that attack surface while keeping the service useful. You do not collect isolated directives and call the job finished. You define what traffic should reach each boundary, reject what falls outside that policy, and preserve enough evidence to detect mistakes and abuse.

A practical mental model has six layers:

Keep the NGINX build and its dependencies supported and patched.
Expose only the listeners, modules, files, and routes the service needs.
protect client and upstream traffic with verified TLS.
Bound request cost with size, time, rate, connection, and method controls.
Make identity and trust explicit for client addresses, protected locations, and upstream systems.
Test changes, reload safely, and watch logs for rejected or unusual traffic.

Each layer covers a different failure mode. Hiding the version does not patch a vulnerable binary. TLS does not authorize a request. A rate limit does not repair an application flaw. A web application firewall does not make an unsafe origin safe. Defense in depth works because the layers overlap without being mistaken for one another.

Start with inventory, not a template

You need to know what NGINX actually runs before you can reduce it. Record the installed version, build options, loaded dynamic modules, included configuration files, listening sockets, certificate files, document roots, log destinations, and upstream endpoints.

The NGINX command-line interface supports two useful checks. nginx -V prints the version and build parameters. nginx -T tests the configuration and also dumps the complete configuration, including included files. This effective configuration is more useful than reviewing one short top-level file in isolation.

Compare the deployed build with the official NGINX security-advisory page and the security notices from your operating-system or package vendor. Patch status is a control of its own. Configuration cannot compensate for a known memory-safety or protocol flaw in an exposed module.

Remove unused listeners and modules where your packaging and deployment model permit it. Restrict access to configuration files, certificate keys, password files, logs, caches, and temporary directories. The HTTPS guide states that a private key should have restricted file access while remaining readable by the NGINX master process.

server_tokens off; removes the NGINX version from generated error pages and from the Server response header value. This reduces casual disclosure. It does not hide that the server behaves like NGINX, and it does not change the installed code.