A practical look at how Web Application Firewalls analyze HTTP requests, detect attacks, and fit into modern DevOps infrastructure.

A Web Application Firewall (WAF) protects web applications by inspecting HTTP requests at the application layer.

Unlike traditional firewalls, it analyzes:

• URLs


• Query parameters


• Headers


• Cookies


• Request bodies


• File uploads

WAFs detect attacks like:

• SQL Injection


• Cross-Site Scripting (XSS)


• Command Injection


• File Upload Exploits


• Application-layer DDoS

But they work best when combined with secure coding practices and proper DevOps observability.

Why WAF Still Matters in Modern Infrastructure

If your API or web service is public, it is already being scanned.

Typical traffic hitting public endpoints often looks like this:

GET /phpmyadmin

GET /.env

GET /wp-login.php

GET /admin

GET /api/users?id=1 OR 1=1

These requests are usually automated vulnerability scans.

A WAF acts as a filter between the internet and your application.

Typical deployment architecture:

Internet

|

v

+-----------+

| CDN |

+-----------+

|

v

+-----------+

| WAF |

+-----------+

|

v

+-----------+

| Load Bal. |

+-----------+

|

v

+-----------+

| Web App |

+-----------+

The WAF intercepts every HTTP request before it reaches the backend.

Step-by-Step: How a WAF Processes a Request

A typical WAF request lifecycle looks like this:

Client Request

|

v

Request Parsing

|

v

Rule Matching

|

v

Risk Scoring

|

v

Allow / Block / Log

Step 1: HTTP Request Parsing

Before detection begins, the WAF extracts request fields.

Example request:

POST /api/login HTTP/1.1

Host: example.com

User-Agent: sqlmap

Content-Type: application/json



{

 "username":"admin",

 "password":"' OR 1=1 --"

}

The WAF parses this request into structured fields:

requestMethod = POST

requestURI = /api/login

userAgent = sqlmap

requestBody = JSON payload

headers = HTTP headers

These fields are then inspected by the detection engine.

Step 2: Rule Matching

Most WAF engines rely on signature-based detection.

Example rule detecting SQL injection:

rule_id: 10001

description: Detect SQL injection

match:

  field: requestBody

  pattern: "(union select|or 1=1|sleep\()"

action: block

Example rule detecting vulnerability scanners:

rule_id: 20002

description: Block vulnerability scanners

match:

  field: userAgent

  pattern: "(sqlmap|nikto|nmap)"

action: block

When a request matches a rule, the configured action is executed.

Example: ModSecurity Rule

Many production deployments use NGINX + ModSecurity as a Web Application Firewall.


Below is an example rule that detects common SQL injection patterns in incoming requests.

SecRule REQUEST_URI|ARGS|REQUEST_BODY "@rx (union\s+select|sleep\(|benchmark\()" \

"id:10010,\

phase:2,\

block,\

msg:'SQL Injection attempt detected'"

Step 3: Request Scoring

Modern WAFs rarely block based on a single rule.

Instead, they use a risk scoring model.

Example scoring system:

SQL injection pattern +5

XSS payload +4

Scanner user-agent +2

Suspicious encoding +2

Example threshold:

score >= 5 → block request

score < 5 → allow request

This approach reduces false positives.

Real Attack Example

Example malicious request:

GET /api/products?id=1 UNION SELECT username,password FROM users

Detected pattern:

union select

Response:

HTTP 403 Forbidden

The request never reaches the backend server.

DevOps Example: Rate Limiting

Application-layer attacks often involve high request rates.

Example NGINX rate limiting configuration:

limit_req_zone $binary_remote_addr zone=login_limit:10m rate=10r/s;



server {



  location /login {



    limit_req zone=login_limit burst=20 nodelay;



  }



}

This protects login endpoints from:

brute force attacks

credential stuffing

CC attacks

WAF Logging for Security Monitoring

Logging is critical for security operations.

Example log entry:

{

 "timestamp":"2026-03-05T11:22:09Z",

 "client_ip":"192.168.1.15",

 "uri":"/login",

 "rule_id":10010,

 "attack_type":"SQL Injection",

 "action":"blocked"

}

These logs can be forwarded to:

SIEM systems

security monitoring platforms

incident response pipelines

The Biggest Challenge: False Positives

No WAF is perfect.

Example legitimate request:

GET /search?q=select+product+from+store

A poorly designed rule might detect select as SQL injection.

Solutions include:

whitelisting trusted endpoints

adjusting rule thresholds

disabling noisy signatures

Proper tuning is essential for production environments.

Practical Advice for Engineers

If you operate production systems, consider the following best practices.

1. Always deploy a WAF

Especially for services that are directly exposed to the internet:

• Public APIs
  


• Authentication endpoints (e.g., /login, /auth)
  


• File upload services
  


• Payment or account management systems
  

A WAF can filter large amounts of automated attack traffic before it reaches your application layer.

2. Start in monitor mode

Before enabling blocking rules, it is recommended to run the WAF in monitor (or detection-only) mode.

This allows engineers to:

• observe real traffic patterns
  


• identify potential false positives
  


• understand how rules interact with the application
  

Only after analyzing logs and tuning rules should blocking be fully enabled.

3. Continuously tune rule sets

No rule set works perfectly out of the box.

Production environments often require continuous adjustments such as:

• disabling overly aggressive rules
  


• adjusting anomaly score thresholds
  


• creating endpoint-specific rule exceptions
  

Regular rule tuning significantly reduces false positives while maintaining protection.

4. Implement layered security

A WAF should not be treated as the only security control.

Instead, it should be part of a defense-in-depth strategy that includes:

• input validation at the application layer
  


• strong authentication mechanisms
  


• rate limiting and request throttling
  


• vulnerability scanning and patch management
  


• centralized logging and monitoring
  

Combining multiple defensive layers greatly improves overall security posture.

Final Thoughts

A Web Application Firewall is essentially a programmable HTTP inspection engine that sits between the internet and your application.

By analyzing requests in real time, it can detect and block a wide range of common web attacks before they reach backend services.

However, the effectiveness of a WAF depends heavily on:

• proper configuration
  


• continuous rule tuning
  


• integration with monitoring and security operations
  

When deployed correctly, a WAF can dramatically reduce the attack surface of modern web applications while providing valuable visibility into malicious traffic patterns.