DEV Community

Hawkinsdev
Hawkinsdev

Posted on

Inside a Web Application Firewall: How WAFs Actually Inspect HTTP Traffic

#webdev #beginners #security

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 --"
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Example rule detecting vulnerability scanners:

rule_id: 20002
description: Block vulnerability scanners
match:
  field: userAgent
  pattern: "(sqlmap|nikto|nmap)"
action: block
Enter fullscreen mode Exit fullscreen mode

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'"
Enter fullscreen mode Exit fullscreen mode
Parameter Meaning
REQUEST_URI Inspect the URL path
ARGS Inspect query parameters
REQUEST_BODY Inspect POST request body
@rx Perform regex pattern matching
phase:2 Execute rule after request body parsing
block Deny the request

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
Enter fullscreen mode Exit fullscreen mode

Detected pattern:

union select
Enter fullscreen mode Exit fullscreen mode

Response:

HTTP 403 Forbidden
Enter fullscreen mode Exit fullscreen mode

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;

  }

}
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)