DEV Community

Divinelab.io
Divinelab.io

Posted on

How to Block OWASP Top 10 Attacks (Without Breaking Legitimate Traffic)

#devops #opensource #go #security

Most developers turn off Web Application Firewalls (WAFs) within their first week of deployment.

The reason is almost always the same: false positives.

Traditional WAFs rely on crude single-regex pattern matching. If a user submits a blog comment containing a single quote, a search query with the word OR, or an admin saves rich HTML inside a CMS, an overly aggressive WAF will immediately drop the request with a 403 Forbidden.

In this tutorial, we are going to use Aegis—an open-source, self-hosted Web Application Firewall (WAF) and reverse proxy—to block OWASP Top 10 attacks using cumulative anomaly scoring. We will walk through the exact steps to baseline your traffic, configure paranoia levels, test exploit detection, and surgically tune false alarms.

Aegis WAF Dashboard

What Attacks Does OWASP CRS Cover?

Under the hood, Aegis pairs the Go-native Coraza engine with the OWASP Core Rule Set (CRS v4) to protect against the most common web exploit vectors:

  • SQL Injection (SQLi): Malicious SQL syntax inserted into parameters to extract or destroy database records.
  • Cross-Site Scripting (XSS): Injected client-side scripts that hijack user sessions or steal credentials.
  • Remote Code Execution (RCE): Shell commands or payload injections targeting underlying server interpreters.
  • Local File Inclusion (LFI) & Path Traversal: Directory traversal attempts (e.g., ../../etc/passwd) targeting internal system files.
  • Server-Side Request Forgery (SSRF): Forged internal requests querying cloud metadata services (169.254.169.254).

How Cumulative Anomaly Scoring Prevents False Positives

Instead of immediately blocking on the first keyword match, Aegis calculates a cumulative threat score across every rule an HTTP request triggers:

  • Notice: 2 points (slightly irregular character set or header).
  • Warning: 3 points (unusual query structure).
  • Error: 4 points (suspicious payload pattern).
  • Critical: 5 points (clear, deterministic attack signature, such as ' OR 1=1--).

Aegis compares the total points against the Inbound Anomaly Threshold (default: 5).

A casual anomaly alone won't trigger a block, but a real attack string immediately reaches the threshold and gets rejected.

Step 1: Start in "Detection Only" Mode (Safe Baselining)

When introducing a WAF to production, you should never turn on hard blocking immediately.

  1. Open your Aegis Admin Console at http://localhost:8081.
  2. In the sidebar under Configuration, select WAF Core > Overview.
  3. Set the Enforcement Mode to Detection Only.
  4. Click Save Changes.

Aegis WAF Rulesets

Why this matters: In Detection Only mode, Aegis analyzes every incoming request and logs all detected signatures to the Threat Inspection Log, but never blocks users. This lets you observe normal customer traffic for 24–48 hours to confirm zero false alarms before turning on active mitigation.

Step 2: Choose the Right Paranoia Level

On the same Overview page, adjust the Paranoia Level slider to match your risk profile:

  • Paranoia Level 1 (Default - Recommended): Applies high-confidence rules designed to catch obvious attacks with virtually zero false positives. Best for standard websites, APIs, and blogs.
  • Paranoia Level 2: Adds stricter validation on input lengths and special characters. Recommended for user portals and e-commerce checkouts.
  • Paranoia Level 3 & 4: Rigorous payload inspection and strict character encoding rules. Best for high-security banking, healthcare, or government environments where you have dedicated engineering time to tune exceptions.

Step 3: Switch to "Active Blocking"

Once you verify that legitimate traffic passes through without anomaly warnings:

  1. Change the Enforcement Mode switch to Active Blocking.
  2. Click Save Changes.

Aegis reloads the security policy dynamically in memory with zero downtime—no proxy restarts required.

Step 4: Verify Exploit Mitigation with curl

Now verify that real attack payloads are dropped at the network edge before reaching your origin servers.

Test A: SQL Injection (SQLi)

Send an injection attempt in the query string:

curl -i "http://localhost:8080/?id=1%27%20OR%201=1--"
Enter fullscreen mode Exit fullscreen mode

Response:

HTTP/1.1 403 Forbidden
Content-Type: text/html; charset=utf-8
X-WAF-Rule-ID: 942100

Access denied: This request was rejected by the application security layer.
Enter fullscreen mode Exit fullscreen mode

Aegis matches rule 942100 (SQLi attack), calculates a critical anomaly score of 5, and immediately returns a 403 Forbidden.

Test B: Reflected Cross-Site Scripting (XSS)

Send a script tag in a POST body:

curl -i -X POST http://localhost:8080/submit \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "comment=<script>alert('xss')</script>"
Enter fullscreen mode Exit fullscreen mode

Response:

HTTP/1.1 403 Forbidden
X-WAF-Rule-ID: 941100
Enter fullscreen mode Exit fullscreen mode

The XSS payload is dropped at the ingress layer.

Resources

The Community Edition is free to self-host for your own homelabs and production servers:

Top comments (0)