Reverse Proxy and WAF: Protecting Web Applications from Attacks

What a reverse proxy does

A reverse proxy is a server that sits between the internet and your backend web servers. Every request from the internet first goes to the reverse proxy. The reverse proxy inspects the request, processes it if necessary and forwards it to the appropriate backend server. The backend server's response travels the same path back.

From the user's perspective, they communicate with the reverse proxy, not with the backend server. The backend server is not directly reachable from the internet. This alone is already a significant security gain.

Functions of a reverse proxy

Load balancing. Distributes requests across multiple backend servers. If one server fails, the reverse proxy automatically redirects requests to the remaining servers.

SSL/TLS termination. The reverse proxy handles the encryption and decryption of HTTPS traffic. The backend servers communicate unencrypted with the reverse proxy (or via an internal certificate). This simplifies certificate management and offloads the backend servers.

Caching. Frequently requested content (static files, API responses) is cached by the reverse proxy and served directly without burdening the backend server.

Header manipulation. The reverse proxy can add, remove or modify HTTP headers: set security headers (Content-Security-Policy, Strict-Transport-Security), remove internal server headers (X-Powered-By, Server), forward client IP addresses (X-Forwarded-For).

Access control. Rate limiting (limiting requests per IP), geo-blocking (blocking requests from specific countries), IP whitelisting/blacklisting.

Web application firewall. The central function for this article: the reverse proxy analyses every request for malicious content and blocks attacks before they reach the backend server.

What a WAF does

A Web Application Firewall (WAF) operates at the application layer (Layer 7 of the OSI model). While a network firewall checks IP addresses, ports and protocols, a WAF analyses the content of HTTP/HTTPS requests and responses: URLs, query parameters, form data, cookies, HTTP headers, request body.

Threats a WAF protects against

The OWASP Top 10 are the benchmark for web security risks. A well-configured WAF protects against most of these threats:

SQL injection (A03). The attacker injects SQL commands into input fields to manipulate or read the database. Example: ' OR '1'='1 in a login field. The WAF detects SQL syntax in HTTP parameters and blocks the request.

Cross-site scripting / XSS (A03). The attacker injects JavaScript code into web pages that executes in other users' browsers. Example: <script>document.cookie</script> in a comment field. The WAF detects script tags and event handlers in input fields.

Path traversal (A01). The attacker manipulates file paths to access files outside the intended directory. Example: ../../etc/passwd in a file parameter. The WAF detects directory traversal patterns.

Remote code execution (A08). The attacker injects executable code into the application. The WAF detects suspicious payloads that indicate code execution.

Server-side request forgery / SSRF (A10). The attacker tricks the server into sending requests to internal resources. The WAF detects requests containing internal IP addresses or localhost URLs.

Brute-force attacks. Automated login attempts with stolen credentials. The WAF detects and rate-limits repeated failed login attempts.

Bot traffic. Automated access by scrapers, crawlers and malicious bots. The WAF detects bot signatures and unusual access patterns.

WAF rule sets

OWASP Core Rule Set (CRS)

The OWASP Core Rule Set is a freely available, community-maintained rule set for WAFs. It is the de facto standard for open-source WAFs and is supported by ModSecurity, Coraza, Caddy-WAF and several commercial WAFs.

The CRS works with a scoring system: each rule that detects an anomaly in a request awards points. If the total score of a request exceeds a configurable threshold (default: 5 for inbound requests), the request is blocked.

This system has a crucial advantage over simple pattern matching: a single suspicious string in a long form does not immediately trigger a block. Only the combination of multiple suspicious indicators leads to blocking. This significantly reduces false positives.

Paranoia levels

The CRS has four paranoia levels (PL1 to PL4) that control detection sensitivity:

PL1 (default): Basic rules that detect the most obvious attacks. Few false positives. Recommended as a starting point.

PL2: Additional rules that detect more subtle attack patterns. More false positives that need tuning.

PL3: Aggressive detection, high false positive rate. For applications with high protection requirements.

PL4: Maximum detection, many false positives. Only for particularly critical applications after extensive tuning.

Start with PL1 and increase gradually after addressing the false positives at each level.

Deployment options

Option 1: Nginx + ModSecurity / Coraza

The classic open-source solution. Nginx as the reverse proxy, ModSecurity (or its successor Coraza) as the WAF engine, OWASP CRS as the rule set.

Nginx is the most widely used reverse proxy and web server. It is lightweight, performant and extremely well documented.

ModSecurity is the traditional WAF engine that works with the OWASP CRS. Note: ModSecurity 3 (libmodsecurity) has not been actively developed since 2024. The recommended successor is Coraza, a WAF engine written in Go that is fully compatible with the OWASP CRS and actively maintained.

Typical setup:

1. Nginx as a reverse proxy in front of your web applications
2. Coraza as a WAF module integrated into Nginx
3. OWASP CRS loaded as the rule set
4. SSL termination with Let's Encrypt certificates (automatic renewal via certbot)
5. Logging to central log management

Option 2: Traefik + CrowdSec

A more modern alternative, especially for container-based environments.

Traefik is a reverse proxy designed specifically for dynamic infrastructures (Docker, Kubernetes). It discovers backend services automatically and configures itself.

CrowdSec is an open-source security platform that functions as a WAF complement. It analyses logs and access patterns, detects malicious behaviour and blocks attackers. Distinctive feature: CrowdSec shares threat intelligence across all community participants. If an IP address is detected as malicious by another CrowdSec user, it is also blocked for you.

Option 3: Firewall-integrated WAF

Many NGFWs offer an integrated WAF function: Fortinet FortiWeb, Sophos WAF (in the XGS series), Barracuda WAF, F5 BIG-IP ASM.

Advantages: Central management, no additional infrastructure, integration with the existing firewall ecosystem. Disadvantages: Often less flexible than dedicated solutions, performance impact on the firewall, sometimes limited rule set customisation.

Option 4: Cloud WAF

Cloud-based WAFs sit in front of your entire web infrastructure and filter traffic before it even reaches your network. You change your DNS records so that traffic first passes through the cloud WAF.

Cloudflare WAF: The market leader for cloud WAF. Easy setup (DNS change), extensive rule set, DDoS protection included, bot management. Free tier available, Pro and Business plans for advanced WAF features.

AWS WAF: For applications running on AWS. Flexible rule configuration, integration with CloudFront and Application Load Balancer.

Azure Front Door + WAF: For Azure-based applications. Managed rule set based on OWASP CRS.

Advantages of cloud WAFs:

• No own infrastructure needed
• Automatic signature updates
• DDoS protection often included
• Global network reduces latency
• Easy setup

Disadvantages of cloud WAFs:

• All your web traffic passes through a third-party provider
• Privacy concerns (particularly with US providers and GDPR)
• Dependence on the cloud provider (provider outages affect your website)
• Ongoing costs that grow with increasing traffic
• Less control over the rule set

SSL/TLS termination: best practices

The reverse proxy typically handles SSL/TLS termination. This has several advantages:

• Central certificate management in one place instead of on every backend server
• Automatic certificate renewal with Let's Encrypt / ACME
• Performance offloading for backend servers
• Ability for SSL inspection (WAF can analyse the decrypted traffic)

TLS configuration

Configure the reverse proxy with current TLS settings:

• At least TLS 1.2, ideally TLS 1.3 (TLS 1.0 and 1.1 are outdated and insecure)
• Cipher suites: Allow only strong cipher suites. TLS 1.3 exclusively uses AEAD ciphers (AES-256-GCM, ChaCha20-Poly1305). For TLS 1.2: prefer ECDHE-based cipher suites.
• HSTS (HTTP Strict Transport Security): Set a header that tells the browser to access the website only via HTTPS. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• OCSP stapling: Accelerates certificate validation and reduces dependence on external OCSP servers.

Security headers

The reverse proxy is the ideal place to set security headers that the backend applications do not set themselves:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

These headers protect against XSS, clickjacking and other browser-side attacks.

WAF tuning: the critical success factor

A WAF in default mode will block legitimate requests. An online shop whose product descriptions contain HTML fragments, a CMS whose editor sends JavaScript code in forms, an API endpoint that processes JSON payloads with special characters -- all of this can trigger WAF rules.

Step-by-step approach

Phase 1: Detection mode (2 to 4 weeks). The WAF analyses traffic and logs suspicious requests but blocks nothing. You collect data and understand which rules fire for your specific application.

Phase 2: False positive analysis. Review the logged alerts and identify false positives. Typical sources:

• Form fields that contain HTML or SQL-like syntax (e.g. CMS editors)
• API endpoints that transmit Base64-encoded data
• Upload functions that accept files with suspicious content
• Monitoring and health check requests

Phase 3: Configure exceptions. For each confirmed false positive, configure an exception:

• Disable specific rules for specific URLs (e.g. SQL injection rules for the CMS editor endpoint)
• Exclude specific parameters from inspection (e.g. the content parameter of the WYSIWYG editor)
• Adjust the anomaly threshold for specific paths

Phase 4: Activate prevention mode. Switch the WAF to blocking mode gradually. Start with the least critical applications and expand step by step. Monitor the logs intensively in the first days after switching.

Phase 5: Continuous monitoring. Permanently monitor WAF logs for new false positives (e.g. after an application update) and for actual attacks. In ISMS Lite, you document the WAF configuration as a technical control and track tuning cycles as a recurring task. Update the rule set regularly (OWASP CRS publishes updates several times a year).

Rate limiting and DDoS protection

Beyond the WAF function, the reverse proxy offers another important protection layer: rate limiting. You limit the number of requests a client (identified by IP address) may send within a given time period.

Typical rate limits:

• Login endpoints: 5 requests per minute per IP (brute-force protection)
• API endpoints: 100 requests per minute per API key
• General pages: 60 requests per minute per IP

Rate limiting protects against brute-force attacks, simple DDoS attacks and automated scraping. Against distributed DDoS attacks with thousands of IP addresses, rate limiting alone is insufficient -- for that you need an upstream DDoS protection service (Cloudflare, AWS Shield or similar).

Architecture: reverse proxy in the DMZ

The reverse proxy belongs in the DMZ, not in the internal network. The architecture:

1. Internet traffic reaches the reverse proxy in the DMZ
2. The reverse proxy terminates SSL, checks WAF rules and forwards legitimate requests
3. Forwarding occurs through the firewall into the server zone
4. The firewall allows only defined traffic from the reverse proxy to the backend servers (port 80/443, only the reverse proxy's IP)
5. The backend servers are not directly reachable from the internet

If the reverse proxy is compromised, the attacker has access to the DMZ but not to the server zone. The firewall between the DMZ and the server zone prevents lateral movement.

Monitoring and alerting

What you should monitor

• Blocked requests per hour: A sudden increase may indicate a targeted attack
• Top 10 blocked rules: Shows the most common attack types
• Top 10 attacked URLs: Shows which endpoints are attacked most
• Top 10 attacker IPs: Shows the most active attackers
• Backend server response times: An increase may indicate an application-layer DDoS
• Error rate (5xx responses): May indicate problems caused by WAF blocking

Alerting

Configure alerts for:

• More than X blocked requests per minute from a single IP (targeted attack)
• More than X different attacker IPs per hour (distributed attack)
• New attack patterns not previously observed
• Backend server unreachable (outage)
• SSL certificate expires in less than 14 days

Further reading

• Firewall configuration for SMEs: rules, zones and best practices
• Intrusion detection and prevention (IDS/IPS) for mid-market companies
• DNS security: DNS filtering, DNSSEC and DNS over HTTPS
• Building vulnerability management: scanning, assessing, remediating
• Network segmentation for SMEs: why and how to segment your network

A reverse proxy with WAF is no guarantee for the security of your web applications. SQL injection vulnerabilities still need to be fixed in the code, and a secure development lifecycle remains indispensable. But a WAF provides an additional layer of defence that blocks attacks while vulnerabilities are being fixed and catches zero-day exploits for which no patch yet exists. In a time when web applications are the most frequent attack target, this layer is not optional.