DEV Community: Divinelab.io

How to Automatically Redact Leaked API Keys and .env Files at the Edge

Divinelab.io — Fri, 09 Oct 2026 08:18:31 +0000

Every developer dreads accidental secret exposure: a debug route left enabled that dumps an unredacted .env file, an uncaught database connection error that exposes credentials in a stack trace, or an internal API returning private keys to the browser.

Most Web Application Firewalls only inspect inbound requests. But protecting your backend also requires inspecting outbound responses before they leave the network.

In this tutorial, we are going to use Aegis—an open-source, self-hosted Web Application Firewall (WAF) and reverse proxy—to configure native Sensitive Data Leak Protection (DLP) and automatically redact leaked API keys, tokens, and environment variables in real time.

Step 1: Access Leak Protection Settings

Open your Aegis Admin Console at http://server-ip:8081.
In the left navigation menu, navigate to WAF Core > Leak Protection.
Toggle on Enable Leak Protection.

Aegis will now stream outbound HTTP response bodies from your origin servers through in-memory pattern validators.

Step 2: Choose Your Response Action

Select how Aegis handles detected credentials and secrets:

Redact Matches (redact) — Recommended: Replaces sensitive values with [REDACTED] in the response stream. The web page continues to function for the user, but the secret is scrubbed before leaving the network.
Block Responses (block): Immediately halts delivery and returns an HTTP 403 Forbidden with a generic security block page. Best for strict regulatory environments (PCI-DSS, HIPAA).
Monitor Only (detect): Permits the response while logging an alert to security telemetry for auditing.

Click Save to apply the policy in memory.

Step 3: Test Real-Time Secret Redaction

Imagine an origin backend accidentally prints an AWS key or database URI in an API response:

{
  "status": "success",
  "data": {
    "provider": "aws",
    "access_key": "AKIAIOSFODNN7EXAMPLE"
  }
}

Send a request through the Aegis proxy with Redact enabled:

curl -s http://localhost:8080/api/config

Response received by the client:

{
  "status": "success",
  "data": {
    "provider": "aws",
    "access_key": "[REDACTED]"
  }
}

The credential is neutralized at the network edge without requiring any code modifications or redeployments to your backend application.

Step 4: Configure Scoped Exceptions for Sandboxes

If you have specific diagnostic endpoints or test environments that legitimately need to return mock tokens:

Click the Allowlist Exceptions tab.
Click + Add Exception.
Specify the URL path (e.g., /api/v1/sandbox/*).
Set an optional expiration date.
Click Save Exception.

The exception applies immediately in memory with zero service restarts.

Resources

The Community Edition is free to self-host:

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

How to Stop Bad Bots and AI Scrapers

Divinelab.io — Fri, 09 Oct 2026 08:17:54 +0000

Automated scrapers, AI training crawlers, and credential stuffing bots account for over 40% of all internet traffic.

Allowing bots to scrape your web application without restrictions inflates hosting bills, degrades performance for real users, and drains database connection pools.

In this tutorial, we are going to use Aegis—an open-source, self-hosted Web Application Firewall (WAF) and reverse proxy—to configure automated bot defense, manage AI scrapers, and deploy client-side cryptographic browser challenges.

Step 1: Access Bot Defense Settings

Open your Aegis Admin Console at http://server-ip:8081.
In the left navigation menu, navigate to Traffic Control > Bot Defense.
Toggle on Enable Bot Protection.

Aegis evaluates incoming client fingerprints, request headers, and traffic behavioral patterns in real time.

Step 2: Configure AI Crawlers and Scraper Policies

Manage how automated crawlers access your site:

Search Engine Crawlers: Toggle on Allow Verified Search Engines (Googlebot, Bingbot, DuckDuckGo). Aegis verifies reverse-DNS signatures to ensure fake bots cannot spoof search engine user-agents.
AI Scrapers & Training Bots: Select your policy for known AI crawlers (GPTBot, CCBot, Anthropic, Bytespider):
- Block: Immediately drop requests with HTTP 403 Forbidden.
- Challenge: Require the bot to pass a client-side challenge.
Click Apply Policy.

Step 3: Deploy Client-Side Browser Challenges (Smart Challenge)

For requests that exhibit suspicious behavior or exceed baseline request velocities:

Under Mitigation Strategy, select Browser Challenge (Smart Challenge).
When a suspected bot requests a protected page, Aegis returns a lightweight HTML payload that executes a fast cryptographic challenge in the background.
Genuine human visitors running modern web browsers solve the challenge automatically in milliseconds without seeing a CAPTCHA.
Headless scripts, scraping tools, and automated botnets fail the execution and are dropped at the edge.

Step 4: Verify Bot Mitigation

Test the endpoint with an automated CLI client:

curl -i -A "GPTBot/1.0" http://localhost:8080/

Response:

HTTP/1.1 403 Forbidden
Content-Type: text/html; charset=utf-8
X-Aegis-Action: bot-blocked

Access denied: Automated AI scraper blocked by security policy.

The request is rejected at the ingress proxy and never reaches your origin web server.

Resources

The Community Edition is free to self-host:

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

How to Block Malicious Traffic by Country

Divinelab.io — Fri, 09 Oct 2026 08:16:22 +0000

If your web application or internal dashboard only serves users in specific countries, allowing unrestricted global access unnecessarily exposes your login routes and APIs to automated botnets and brute-force scans originating from overseas bulletproof hosting providers.

In this tutorial, we are going to use Aegis—an open-source edge security gateway and reverse proxy—to configure Geo-IP Blocking and IP Reputation Denylists to drop unwanted traffic before it consumes origin server resources.

Step 1: Access the Geo-Blocking Console

Open the Aegis Admin Console at http://server-ip:8081.
In the sidebar under Traffic Control, select Geo-Blocking.
Toggle on Enable Geo-IP Enforcement.

Aegis uses an embedded MaxMind GeoLite2 country database to look up client IP geographic origins in sub-microsecond in-memory evaluations.

Step 2: Choose Your Policy Mode and Countries

Select the appropriate enforcement strategy for your application:

Denylist Mode (Most Common): Allows traffic globally, but explicitly drops connections originating from countries where you observe malicious scanning (e.g., select target countries from the world map).
Allowlist Mode: Drops all international traffic by default, only permitting requests from specified countries (ideal for regional SaaS or compliance-constrained workloads).
Click Apply Policy.

Aegis reloads the routing table dynamically in memory with zero downtime.

Step 3: Add Dynamic IP & CIDR Blocklists

Under Traffic Control > Blacklist / Allowlist:

Click + Add Entry.
Enter a specific offending IP (203.0.113.50) or an entire malicious subnet (198.51.100.0/24).
Set an Expiration Duration (e.g., ban for 24 hours, or select permanent ban).
Save the entry to enforce the drop immediately at the TCP/HTTP layer.

Step 4: Verify Blocked Traffic

Test from a restricted IP or verify via curl:

curl -i http://localhost:8080/

Blocked responses are rejected immediately at the edge without opening any connection to your backend servers:

HTTP/1.1 403 Forbidden
Content-Type: text/html; charset=utf-8
X-Aegis-Action: geo-blocked

Access denied: Connections from your geographic region are not permitted.

Resources

The Community Edition is free to self-host:

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

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