SerpWise Shield

SerpWise Shield is a set of security features that run at the gateway layer, before traffic reaches your origin server. Because Shield evaluates requests before they are forwarded to origin, it protects your server from both the load and the risk of malicious probing.

Shield is configured per-domain from the Shield tab in your domain dashboard.

Exploit Path Protection

Automated scanners and bots routinely probe websites for common vulnerabilities — attempting to access configuration files, admin panels, and known exploit endpoints.

Shield maintains a list of known exploit paths and blocks any request that matches:

.env
.git/config
wp-config.php
wp-login.php
xmlrpc.php
/etc/passwd
/proc/self/environ
phpmyadmin/
adminer.php
shell.php

...and dozens more patterns covering WordPress exploits, PHP shells, configuration file exposure, and path traversal attempts.

What happens when a match is found:

1. The request is blocked immediately — your origin server never receives it
2. The gateway returns a 403 Forbidden response
3. The source IP is automatically blackholed for 24 hours

IP Blackhole

When an IP address triggers the exploit shield, it is added to an automatic blackhole. For the next 24 hours, all requests from that IP receive a 403 Forbidden response — regardless of the path being requested.

This prevents scanners from continuing to probe your site using different paths after their initial exploit attempt is blocked.

The blackhole is maintained in-memory per gateway instance and resets automatically after 24 hours.

Rate Limiting

Rate limiting protects your origin server from traffic floods by restricting the number of requests a single IP address can make within a time window. When an IP exceeds the limit, the gateway returns a 429 Too Many Requests response without forwarding the request to your origin.

Rate limiting uses a sliding window algorithm — request counts are tracked continuously rather than resetting at fixed intervals, which prevents burst exploitation at window boundaries.

Configuration

Configure these from the Shield tab → Rate Limiting section.

Response Headers

Rate-limited responses include standard headers that clients and CDNs can use to implement backoff logic:

Allowed requests also receive X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers so clients can proactively manage their request rate.

Rate Limiting Analytics

When rate limiting is enabled, the Shield tab displays analytics below the configuration form:

• Blocked Requests — total number of 429 responses in the last 30 days, with block rate percentage
• Top Blocked IPs — ranked list of IP addresses that were rate-limited most frequently
• Blocks Over Time — daily chart of rate-limited requests

Rate-limited requests also appear in the main Analytics tab as a "Blocked Requests" KPI card with a sparkline trend.

Enabling Shield Features

Each Shield feature can be toggled independently:

1. Navigate to your domain in the dashboard
2. Click the Shield tab
3. Toggle Exploit Shield, Rate Limiting, or any combination
4. Save — changes take effect on the next request (no deployment required)

How Shield Compares to Rules

Shield runs before rule evaluation in the request pipeline. This means:

• Exploit-blocked requests never reach the rules engine or origin
• Rate limiting is evaluated before rules — limited requests return 429 immediately

For HTTP security header injection (HSTS, CSP, X-Frame-Options, etc.), see the Security Headers tab in your domain dashboard. For per-page or conditional header control, use the set_response_header and remove_response_header rule actions.

Limitations

• IP blackhole is not persistent — resets on gateway restart
• IP blackhole is not shared — if you run multiple gateway instances, each maintains its own blackhole
• Exploit paths list — the list is maintained by SerpWise and updated periodically; you cannot add custom patterns (use rules with url.path matches_regex conditions if you need to block custom paths)
• Rate limit counters are in-memory — they reset on gateway restart and are not shared across gateway instances
• Rate limiting is per-IP — it does not support per-path or per-endpoint limits; all requests from an IP count against the same window