When you add a website to SecureShield, you get scheduled outside-in scans by default — no DNS changes, nothing to configure. Fill in an origin server and point your domain at us, and you can opt into a second mode: SecureShield sits in front of your traffic as a reverse proxy. Most tools make you pick one of these as their whole identity. Here's why we don't think that's the right call, and what you're actually trading off between them.
Mode one: scanning from the outside
Every 15 minutes, SecureShield's scheduler reaches out to each verified website the same way a visitor's browser would: it resolves the domain, makes a request, and reads what comes back. From that single request it checks three things:
Is it up
A straightforward reachability check. Repeated failures get logged as a downtime threat rather than a one-off blip — nobody wants an alert every time a single request times out.
Is the SSL certificate healthy
How many days remain before expiry, surfaced well before the browser warning page would be the first anyone hears about it.
Are the right security headers present
The six-header score covered in our other post, graded A through F.
This mode needs nothing from you beyond a domain. It can't see individual requests hitting your site, and it can't block anything — it only reports what it finds.
Mode two: sitting in front of your traffic
Add an origin server — your site's real hostname or IP — and point your public domain's DNS at SecureShield instead, and every visitor request now reaches SecureShield first. Each request is checked against a set of block rules before it's forwarded on:
- SQL injection patterns in the path or query string
- Obvious XSS payloads — inline scripts,
onerror=,javascript:URLs - Path traversal attempts (
../and its encoded variants) - Probes for sensitive files —
.env,.git/config,wp-config.php - Known scanner user-agents, like sqlmap or Nikto
Anything that matches gets a 403 before it ever reaches your server. Everything else — the overwhelming majority of traffic — passes through, and now SecureShield can show you real request and block counts on the Analytics page, not just periodic snapshots.
We're upfront that these rules are deliberately simple, conservative regex patterns — a solid first layer against opportunistic scanning, not a replacement for a dedicated WAF like Cloudflare or AWS WAF if you're handling high-value or high-traffic targets. False negatives are expected; the goal is catching the common, automated stuff without accidentally blocking legitimate requests.
The honest tradeoff
Proxying adds a hop. Every request now goes visitor → SecureShield → your server → SecureShield → visitor, instead of going straight to your server. On Render's free tier especially, that's noticeably more latency than a direct connection — expected behavior for a free-tier test, not a bug, but worth knowing before you flip it on for a production site that's latency-sensitive.
That's the whole reason it's optional rather than the default. Outside-in scanning gets you real visibility with zero risk and zero setup. Proxying gets you active blocking and real traffic data, at the cost of a bit of latency and a DNS change you control. Most people start with the first, and turn on the second only for the domains where blocking actually matters.
See both modes in your dashboard
Add a website to start scanning immediately — proxying is one toggle away whenever you're ready.
Get Started