Summary

• HTTPS and redirects
  • Always serve public sites over HTTPS — browsers may warn or block non-HTTPS sites.
  • Enforce HTTPS by redirecting HTTP to HTTPS at the web server or reverse proxy level to ensure all users automatically use the secure site.
• SSL and TLS
  • Use TLS (the modern protocol) rather than older SSL versions.
  • For local development, use tools like mkcert to create locally trusted certificates; plain self-signed certs are typically marked untrusted by browsers.
  • For production, obtain certificates from trusted CAs such as Let’s Encrypt (free) or commercial providers like DigiCert or Comodo.
• HTTP headers — why they matter
  • HTTP headers control content negotiation, caching, and security behaviors. Properly configured headers are essential for reverse proxies, load balancers, and web servers.
  • Reverse proxies commonly forward these headers to backends: Host, X-Forwarded-For, X-Forwarded-Proto, and X-Real-IP.
  • Cache-control headers include Cache-Control, Expires, ETag, and Last-Modified.
  • Security headers reduce attack surface and harden browsers against common threats.

​

Reverse proxy use cases

• TLS termination (offloading TLS from backends)
• Request routing and virtual hosting
• Load balancing and health checks
• Injecting or forwarding headers so backends receive correct client context

​

Recommended security headers (quick reference)

​

Authentication and access control with NGINX

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;

    location /protected {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://backend;
    }
}

​

IP allow/deny directives and scaling considerations

location /admin {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://admin-backend;
}

• Useful for small, static lists (e.g., internal admin panels restricted to a corporate subnet).
• Not recommended as the primary defense for large-scale or automated responses — maintaining long lists is error-prone.
• For automated or large-scale blocking, use tools like Fail2Ban to monitor logs and manage dynamic bans.

​

Operational recommendations (checklist)

• Enforce HTTPS and redirect HTTP traffic to HTTPS at the proxy layer.
• Use HSTS and other security headers in production.
• Automate certificate issuance and renewal (for example, use Certbot with Let’s Encrypt).
• Consistently forward client headers (X-Forwarded-For, X-Forwarded-Proto, Host) to backends to preserve client context.
• Prefer centralized identity providers (OAuth, SSO) for public authentication needs.
• Use Fail2Ban or WAF systems for dynamic protection and automated blocking of abusive IPs.
• Regularly audit header sets and CORS/CSP policies to ensure you’re not inadvertently exposing sensitive capabilities.

​

Additional references

• NGINX Official Site
• Let’s Encrypt
• mkcert — Simple Zero-CA for Development
• Certbot Documentation
• Fail2Ban Project