Nginx · The edge of your stack

How do you harden an Nginx deployment?

HardsecurityhardeningcspUpdated Oct 2026
Quiz this track

Short answer

Reduce exposed surface, run workers unprivileged, keep Nginx patched, enforce TLS, add security headers, limit body size and request rates, restrict internal endpoints and review every proxy trust boundary.

Hardening is layered. Nginx can enforce transport, header and request-shape controls, but it cannot fix application authorization bugs. The goal is to reduce attack surface and make abuse expensive without blocking legitimate traffic.

nginx
server_tokens off;
client_max_body_size 2m;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/tls/example.com.crt;
    ssl_certificate_key /etc/nginx/tls/example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    add_header X-Content-Type-Options "nosniff" always;
    add_header Content-Security-Policy "default-src 'self'" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location ~ /\.(?!well-known) {
        deny all;
    }

    location = /login {
        limit_req zone=login burst=5 nodelay;
        proxy_pass http://auth;
    }
}

Controls worth having

  • Run workers as an unprivileged user and keep secrets out of the config repository
  • Patch Nginx and modules promptly and remove unused modules
  • Disable autoindex, hide version tokens and restrict status endpoints to localhost
  • Set body size limits and timeouts to curb resource exhaustion
  • Rate limit authentication and expensive endpoints more strictly than general traffic
  • Validate and normalize forwarded headers, and reject ambiguous request framing at the edge
  • Add a WAF or upstream filtering only with tuning, because a default ruleset can cause false positives
Security headers are defense in depth, not a replacement for output encoding or authorization. Roll out a strict CSP in report-only mode first, because a broken CSP can block the application's own scripts.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Which Nginx controls help against credential stuffing?
  2. 2Why is server_tokens off not a real security boundary?
  3. 3How do you roll out a strict Content-Security-Policy safely?
  4. 4What request smuggling risks should an edge proxy consider?

Say it in the interview

I harden in layers: unprivileged workers, patched versions, modern TLS, security headers, body limits, timeouts and stricter limits on login routes. I hide version tokens, restrict internal endpoints and validate forwarded headers and request framing at the proxy boundary. I treat headers as defense in depth and roll out CSP in report-only mode before enforcing it.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Nginx mock interview and get scored feedback on depth, clarity and confidence.