DEV Community: Divinelab.io

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

Divinelab.io — Mon, 05 Oct 2026 15:11:51 +0000

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.

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.

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

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:

Change the Enforcement Mode switch to Active Blocking.
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--"

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.

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>"

Response:

HTTP/1.1 403 Forbidden
X-WAF-Rule-ID: 941100

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:

Aegis GitHub Repository: https://github.com/divinelabio/aegis
Documentation: https://divinelab.io/products/aegis/docs/waf-core/overview

How to Stop API Floods and Rate Limit Endpoints in Under 5 Minutes

Divinelab.io — Mon, 05 Oct 2026 15:07:22 +0000

Exposing an API or web application to the public internet means dealing with credential stuffing, scraping bots, and sudden volumetric request surges.

If you don't enforce rate limits and connection thresholds at the network edge, an attacker can easily exhaust your database connection pools or CPU resources.

In this guide, we'll configure Aegis—an open-source, self-hosted edge reverse proxy and WAF—to rate limit abusive clients and prevent Layer 7 denial-of-service attacks directly from its web console.

1. Configure Global Flood Protection

In the Aegis Admin Console (http://localhost:8081), navigate to Traffic Control > Application Flood.

Aegis tracks request velocity and active socket concurrency per client IP in real time:

HTTP Flood Threshold: Sets the maximum requests per second allowed per IP (e.g., 100 req/s).
In-Flight Connection Ceiling: Caps simultaneous concurrent TCP sockets per IP (e.g., 50 in-flight). This defends origin services against connection exhaustion attacks like Slowloris.
Burst Multiplier: Allows short traffic spikes (e.g., 2.0x) before throttling begins.
Temporary Ban: Automatically blacklists repeated threshold abusers for a set duration (e.g., 60 minutes).

When you click Save, Aegis applies the rules directly in memory with zero downtime—no proxy reloads or dropped connections.

2. Scope Tighter Limits on Sensitive Routes

Global rate limits are often too permissive for authentication endpoints. While 100 req/s makes sense for browsing a product catalog, allowing that on /api/login leaves you vulnerable to brute-force attacks.

In the Protected HTTP Objects panel:

Click + Add Object.
Specify the path: /api/v1/auth/login (Method: POST).
Set a strict limit: 5 req/s with a max concurrency of 2.
Choose the response action: HTTP 429 Too Many Requests or Browser Challenge.

3. Test the Rate Limiter

Send a burst of rapid requests to test edge enforcement:

for i in {1..20}; do
  curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/api/v1/auth/login -X POST
done

Output:

Once the threshold is exceeded, Aegis drops excess requests at the edge with 429 Too Many Requests before they ever reach your origin database.

Resources

Aegis Community Edition is free and open-source under BSL 1.1:

GitHub: https://github.com/divinelabio/aegis
Docs: https://divinelab.io/products/aegis/docs/traffic-control/application-flood

How to set up a self-hosted WAF for Webapps in 2 minutes ?

Divinelab.io — Mon, 05 Oct 2026 14:51:41 +0000

Securing a web application usually means either routing private traffic through a third-party cloud CDN or wrestling with complex Nginx configurations.

Here is how to set up Aegis—an open-source, self-hosted Web Application Firewall (WAF) and reverse proxy—in under two minutes.

1. Install & Deploy Aegis

Choose either the quick installation script or Docker:

Option A: Install via Script (Linux)

Clone the repository and run the automated installer:

git clone https://github.com/divinelabio/aegis.git
cd aegis
sudo bash install.sh

Verify the systemd service is active:

sudo systemctl status aegis

Option B: Deploy via Docker

Run the self-contained container with persistent data storage:

docker run -d --name aegis_server \
  --restart unless-stopped \
  -p 8080:8080 -p 8081:8081 \
  -v aegis_data:/var/lib/aegis/data \
  -e AEGIS_ADMIN_PASSWORD="ChooseStrongAdminPassword123!" \
  ghcr.io/divinelabio/aegis:latest

Port 8080: Public Ingress Proxy (sits in front of your applications).
Port 8081: Web Dashboard for traffic monitoring and policy tuning.

2. Test WAF Attack Blocking

Aegis inspects incoming requests and blocks common web exploits (SQL Injection, XSS, Remote Code Execution) out of the box.

Test it by sending a simulated SQL Injection payload to the proxy:

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

Aegis intercepts the attack and returns HTTP 403 Forbidden:

HTTP/1.1 403 Forbidden
X-WAF-Rule-ID: 942100

Access denied: This request was rejected by the application security layer.

The attack is dropped at the edge and never reaches your backend servers.

3. Manage Routes in the Web Dashboard

Open http://localhost:8081 in your browser.

From the dashboard, you can:

Route incoming traffic to your backend origin servers.
View blocked attacks and threat telemetry in real time.
Adjust Layer 7 rate limits, toggle Geo-IP blocking, and manage SSL certificates.

All policy updates reload dynamically in memory with zero downtime—no proxy restarts required.

Resources

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

GitHub: https://github.com/divinelabio/aegis
Documentation: https://divinelab.io/products/aegis/docs