nginx 1.30

Apply these rules to open-source nginx 1.30 as an HTTP reverse proxy and, where enabled, a stream TCP/UDP proxy. Mail proxying, njs application code, NGINX Plus-only modules, and Kubernetes controller policy need their own guidance.

Build and process boundaries

• Run the newest patch of an nginx line that still receives security fixes. Let a trusted package repository or line-following image tag select the patch, look up current support instead of guessing a version, never loosen an existing constraint to make installation succeed, and audit the deployed binary, modules, TLS library, and image in CI separately from application dependencies.
• Inspect nginx -V for the actual build and enabled modules. Use only trusted modules that the deployment needs; a directive documented for the commercial product is not automatically available in open-source nginx.
• Run workers under a dedicated unprivileged account and grant only the capabilities, files, and network destinations the service needs.
• Keep configuration, included files, dynamic modules, certificates, private keys, and reload control writable only by trusted administrators.
• Keep writable upload, cache, body-temporary, proxy-temporary, and log directories separate from executable code and public document roots.
• Restrict direct access to application backends so clients cannot bypass the proxy's authentication, header rewriting, or transport policy.

Virtual servers and request identity

• Declare the intended listeners and server_name values explicitly, with a default virtual server that rejects unknown