Reverse Proxy Security Checklist for Nginx, HAProxy, and Cloudflare Setups

Overview

Use this article as a living checklist before deployment, during changes, and as part of your regular website compliance audit or infrastructure review. The goal is not to create a perfect one-size-fits-all baseline. The goal is to help you verify the controls that matter most in common reverse proxy deployments:

• Only intended traffic reaches the origin.
• Proxy headers are trusted deliberately, not by default.
• TLS is consistent between client, proxy, and origin.
• Logging and monitoring support cybersecurity compliance without collecting more than you need.
• Rate limits, WAF rules, and bot protections are tested against real application behavior.
• Administrative access is limited, documented, and reviewable.

Although the tooling differs, the core hardening logic is similar across Nginx, HAProxy, and Cloudflare. Think in layers:

1. Edge layer: public listener, TLS, DDoS and bot filtering, request normalization.
2. Proxy layer: routing, header management, request limits, upstream health checks.
3. Origin layer: only receives traffic from approved proxy paths and does not assume headers are trustworthy unless verified.
4. Operations layer: logging, alerting, secrets management, retention, and change control.

If your deployment also involves privacy-sensitive traffic, user identifiers, analytics, or cross-border routing, align proxy changes with your broader privacy compliance process. Related topics include documenting proxy use in records of processing, checking international routing implications, and reviewing whether your setup changes what your privacy notices or contracts should say. For those areas, see GDPR Checklist for Websites Using Proxies, CDNs, and Third-Party Trackers, Cross-Border Data Transfers and Proxies, and How to Document Proxy Use in Your Record of Processing Activities.

Checklist by scenario

This section breaks the reverse proxy security checklist into reusable scenarios. Not every item will apply to every stack, but most teams should review each category.

1) Baseline checklist for any reverse proxy

• Define the trust boundary. Write down exactly where traffic terminates, where TLS is decrypted, and which systems are allowed to forward client IP or protocol headers.
• Restrict origin exposure. Your origin should not be broadly reachable from the public internet if the reverse proxy is intended to be the front door. Limit access by IP allowlisting, private networking, firewall policy, or tunnel-based access.
• Minimize open ports. Expose only the ports and protocols you use. Remove old listeners, test ports, and temporary admin endpoints.
• Use explicit upstream definitions. Avoid ad hoc routing rules that are hard to review. Group backends clearly and document why each one exists.
• Harden TLS. Disable obsolete protocol versions and weak ciphers according to your compatibility requirements. Keep certificate handling and renewal simple enough to audit.
• Set request size and timeout limits. Bound request body size, header size, idle timeouts, and upstream timeout behavior to reduce abuse and failure amplification.
• Sanitize and control forwarded headers. Set or overwrite forwarding headers intentionally instead of passing whatever the client sent.
• Separate public and administrative interfaces. Metrics dashboards, stats pages, API endpoints, and admin consoles should not sit on the same exposure profile as customer traffic.
• Log enough for investigation, but not everything forever. Review whether logs contain full URLs, query strings, authorization material, cookies, or personal data. Define retention and access rules.
• Test failure modes. Confirm what happens when an upstream fails, a certificate expires, DNS changes, or the edge provider is bypassed.

2) Nginx proxy hardening checklist

Nginx is flexible, which is useful and risky at the same time. Configuration drift is a common problem because many small includes and inherited directives can change behavior unexpectedly.

• Review every include file. Security-relevant settings may be split across server, location, and include blocks. Confirm there are no legacy snippets overriding modern defaults.
• Set trusted proxy sources carefully. If you use real IP restoration, trust only known proxy networks. Do not accept client IP headers from arbitrary internet sources.
• Overwrite forwarding headers. Use controlled values for X-Forwarded-For, X-Forwarded-Proto, and host-related headers. Avoid passing through unverified client-supplied values.
• Disable version leakage. Reduce unnecessary server identification in error pages and headers where practical.
• Limit methods where appropriate. If an endpoint only needs GET and POST, do not quietly allow everything else.
• Review path normalization and rewrites. Complex rewrite rules can create access-control gaps, cache confusion, or routing surprises.
• Set upload and buffering limits intentionally. Large body handling, temp file behavior, and buffering settings should match application needs rather than defaults.
• Protect internal locations. Endpoints marked for internal use, health checks, or maintenance should not be reachable externally because of a regex or location precedence mistake.
• Secure status pages and metrics. If you expose Nginx status or exporter endpoints, restrict them by network and authentication.
• Validate error handling. Custom error pages should not reveal internal hostnames, stack details, or backend topology.

3) HAProxy security checklist

HAProxy is often chosen for precision and performance. That precision means frontend, backend, ACL, and header logic should be reviewed as a whole, not line by line in isolation.

• Separate frontends by purpose. Distinguish public HTTP or HTTPS traffic from private admin or health interfaces.
• Review ACL order and fallthrough behavior. Many issues come from a rule that looks correct but is evaluated earlier or later than expected.
• Normalize and set headers at the edge. Remove untrusted incoming forwarding headers and set fresh values for the application.
• Enable strict timeout discipline. Configure client, server, connect, and tunnel timeouts deliberately to reduce resource exhaustion and hanging sessions.
• Protect the stats socket or stats page. Administrative visibility is useful, but it should not become an unauthenticated operational shortcut.
• Use health checks that reflect real service health. A TCP port being open is not always enough. Application-aware checks can prevent routing to degraded backends.
• Review stickiness and session persistence. Persistence can help application behavior, but it may also affect privacy expectations, load distribution, and troubleshooting.
• Check rate limiting and abuse controls. If you use stick tables or request tracking, confirm thresholds are realistic and tested against normal traffic bursts.
• Secure certificate and key handling. Centralized TLS is convenient; key permissions and rotation practices still need review.
• Confirm logging format and destination. Make sure your logs support investigations without exposing secrets or excessive personal data.

4) Cloudflare reverse proxy security checklist

Cloudflare and similar CDN or edge proxy services can add strong protection, but many incidents happen because teams assume the service is securing traffic that still bypasses it.

• Make sure the origin only accepts traffic from the intended edge path. This is one of the most important controls in a Cloudflare reverse proxy security review. If the origin remains directly reachable, attackers may bypass WAF, rate limits, or caching rules.
• Review DNS exposure. Confirm there are no direct-to-origin records, old subdomains, staging hosts, or exposed service records that reveal infrastructure.
• Align SSL mode with real origin security. Avoid configurations that give the appearance of encryption at the edge while weakening the path to origin.
• Use origin authentication where supported. The edge-to-origin connection should be authenticated, not just encrypted.
• Review WAF and bot rules against application behavior. Security rules should be validated with login, checkout, API, search, and webhook flows.
• Protect admin paths separately. Do not rely on a general edge policy alone for dashboards, CMS login pages, or support tools.
• Check caching rules for sensitive content. Make sure authenticated pages, personalized responses, and API outputs are not accidentally cached.
• Understand header changes. Confirm which client metadata, country indicators, bot classifications, and connecting IP headers are passed to origin and how the application interprets them.
• Secure page rules, workers, and edge logic. Custom behavior at the edge should go through the same review process as application code.
• Document regional routing assumptions. If geography matters for privacy compliance or contractual obligations, verify how traffic is handled and what that means operationally. Related reading: Is Using a Proxy Legal? and DPA Checklist for Proxy Providers.

5) Reverse proxy checklist for APIs and web apps

• Protect upstream APIs from direct exposure. The application should expect traffic through the proxy path you designed.
• Preserve method and body behavior carefully. Security controls should not silently break PUT, PATCH, DELETE, streaming, or webhook requests.
• Validate host header handling. Prevent misrouting, open redirect patterns, and application confusion caused by untrusted host values.
• Review WebSocket and upgrade handling. Long-lived connections need their own timeout and monitoring checks.
• Apply authentication-aware rate limits. A per-IP rule alone may be too weak or too disruptive depending on NAT, mobile traffic, or shared networks.
• Make CORS decisions at one layer. Split logic between proxy and app often causes inconsistent enforcement.
• Control request and response headers. Add security headers where appropriate and strip headers that disclose internals.
• Audit logs for tokens and identifiers. APIs often leak secrets through verbose path or query logging.

If your API or proxy is also used for monitoring, scraping, or access control workflows, review the compliance implications before scaling usage. See How to Perform a DPIA for Proxy-Based Monitoring or Web Scraping and Best Practices for Proxy IP Rotation Without Triggering Compliance Problems.

What to double-check

These are the items teams most often think they configured correctly, but should test directly.

• Real client IP handling. Verify the application sees the right client IP only when traffic arrives from trusted proxies. Test with spoofed forwarding headers from an untrusted source.
• Direct-origin bypass. Attempt to reach the origin directly by IP, old DNS names, exposed staging hosts, or alternate ports.
• TLS continuity. Check the client-to-edge and edge-to-origin path separately. A green lock in the browser does not prove the origin path is hardened.
• Security headers. Confirm they appear where expected and are not dropped by caching, redirects, or error responses.
• Cache behavior for authenticated content. Log in as different users and verify personalized pages are never served across sessions.
• Error responses. Trigger common 4xx and 5xx states and inspect whether they expose backend details, internal paths, or software versions.
• Logging scope. Sample raw logs, not dashboards only. Confirm whether cookies, tokens, identifiers, or full query strings are being stored.
• Rate limit false positives. Test API clients, mobile traffic, internal users behind one egress IP, and automated health checks.
• Administrative access paths. Check whether metrics, stats, debug endpoints, or hidden routes are reachable from networks that should not see them.
• Config drift. Compare production config to repository or approved baseline. Proxy layers often change during incidents and never get cleaned up.

This is also the right point to connect hardening work with evidence collection. If your team maps controls for audits or internal review, maintain a simple record of what was tested, by whom, and what evidence was captured. That makes later reviews easier, especially when aligning with broader SOC 2 controls for proxy infrastructure or a recurring website privacy audit.

Common mistakes

The most common reverse proxy failures are rarely exotic. They are usually assumptions that nobody revisited after the first successful deployment.

• Trusting all proxy headers. If the app trusts X-Forwarded-For from any client, your logs, fraud controls, and access decisions may all become unreliable.
• Leaving the origin public. This defeats much of the value of edge protection.
• Treating staging like production without the same controls. Staging domains, preview URLs, and temporary DNS records often become the easiest path around a hardened edge.
• Running with inherited defaults forever. Default timeout, body-size, and cipher choices may not match your current application risk.
• Collecting excessive logs. Detailed logs are useful until they become a quiet privacy and security problem of their own.
• Putting security logic in too many places. Split responsibility across app, proxy, CDN, and load balancer often creates gaps and contradictory behavior.
• Not testing bot controls against real users and integrations. Webhooks, search indexing, payment flows, and mobile apps can be disrupted by overbroad rules.
• Failing to document data flows. If the proxy changes where requests are processed or stored, your privacy compliance records may need updates.

For audit and legal operations teams, this last point matters more than it first appears. Reverse proxies can change processor relationships, log retention patterns, and cross-border data transfer considerations. If a provider or edge service is involved, review contractual terms and technical settings together instead of treating them as separate workstreams.

When to revisit

Use this checklist as a recurring maintenance tool, not a one-time launch exercise. Revisit your reverse proxy security baseline in the following situations:

• Before seasonal planning cycles. High-traffic periods are the wrong time to discover that rate limits, caching rules, or TLS renewals were never tested under load.
• When workflows or tools change. New CDNs, bot tools, WAF rules, upstream APIs, or CI deployment methods can quietly alter the trust boundary.
• After application changes. New paths, authentication methods, upload features, or admin panels often require proxy updates.
• After incidents or near misses. If you had an outage, bypass, credential leak, or false-positive block event, convert the lesson into a checklist item.
• When compliance documentation is updated. A change to retention, hosting, vendor terms, or data flow documentation should trigger a proxy review too.
• When certificates, DNS, or origin architecture changes. These are common moments for hidden regressions.

A practical review cycle can be simple:

1. Pick the relevant scenario from this article: Nginx, HAProxy, Cloudflare, or API-focused deployment.
2. Compare current production behavior to your intended trust model.
3. Test direct-origin access, header trust, TLS path, and log content.
4. Document any exceptions, temporary workarounds, and owners.
5. Schedule the next review date before closing the change.

If you want this checklist to stay useful, keep a short internal version in your runbook and update it whenever defaults, edge providers, or threat patterns change. That approach turns reverse proxy hardening from a heroic clean-up task into a stable part of developer and infrastructure compliance.