Skip to content
ARCHONLABSblackpot.io
Use case · Site Shield

Protect static & personal sites

Turn the scanners hitting your static site into attributed, blocked adversaries — without adding a single script to the pages real visitors load.

Built for
Executives, founders, consultants, small teams on Cloudflare Pages

The problem

A static site has nothing to steal, so nobody watches it. Scanners know that. Every public domain gets a steady drip of requests for /.env, /.git/config, /wp-login.php and /backup.sql — probing for the one misconfiguration that leaks a credential.

Today those requests hit a 404 and vanish. You learn nothing about who sent them, and the same infrastructure moves on to the domains you actually care about.

Site Shield answers those probes instead of ignoring them. It is the pattern we run on our founder’s own executive site: a static résumé on Cloudflare Pages that recruiters, customers and press read every day — untouched — while the scanner traffic beside it gets fingerprinted and blocked.

Request flow

Real visitors
Untouched · 0 scripts
  1. Recruiter, customer, press
    GET /
  2. Cloudflare edge
    no Worker on real paths
  3. Cloudflare Pages
    your site, strict CSP
Scanners
Trapped · attributed · blocked
  1. Attacker
    GET /.env /wp-login.php
  2. Cloudflare edge
    trap path matched
  3. Trap Worker
    real IP + signed edge key
  4. Cloudflare Tunnel
    no inbound ports
  5. blackpot.io sensor
    fake reply · fingerprint · C2 · canary
← Block pushed back

Sensor writes an account-level Cloudflare access rule. The attacker is blocked at the edge on this domain — and every other domain in the account.

Decoy subdomains (staging., dev.) skip the Worker and route through the same tunnel straight to the sensor.

How it works

  1. 01
    Real site untouched

    No scripts, no fingerprinting, no extra hop for real visitors. Pages keep serving the site exactly as before, and your strict CSP stays strict.

  2. 02
    Edge trap paths

    A tiny Cloudflare Worker is bound only to scanner paths on the real domain — /.env*, /.git/*, /wp-login.php, /wp-admin*, /xmlrpc.php, /phpmyadmin*, /backup.sql, /.aws/*, /config.json and more. Real pages never route through it.

  3. 03
    Convincing fakes from the sensor

    The Worker forwards trapped requests to the blackpot.io sensor with the attacker’s real IP and a signed edge key. The sensor answers with a believable fake and starts building the dossier: fingerprint, tooling, C2.

  4. 04
    Decoy subdomains

    staging. and dev. on the same zone route through a Cloudflare Tunnel to the sensor. Scanners find them with subdomain wordlists; nothing on the real site links to them.

  5. 05
    Canary files

    Decoy .env, .zip and .sql files carry canary tokens. If the stolen fake credentials are ever used, the canary trips an alert.

  6. 06
    Block pushed back to the edge

    Enforcement lands as an account-level Cloudflare access rule — the attacker is blocked on this domain and every other domain in the account.

What you get

  • 0 scripts added to your real pages
  • No added latency for real visitors — the Worker only runs on trap paths
  • Strict CSP left exactly as it is
  • Attacker real IP preserved through the edge with a signed key
  • Fingerprint, tooling and C2 extraction on every trapped request
  • Canary-watermarked decoy files that alert on reuse
  • Account-level blocks that cover every domain you own
  • Clean rollback with one command

Set it up

Works with Cloudflare Pages or any site already proxied by Cloudflare. About 10 minutes for a domain already on Cloudflare.

  1. 01 · Describe the site — domain, hosts to arm, decoy names
    $ cp site.env.example sites/yourdomain.com.env
  2. 02 · Dry run — show every route, Worker and DNS record it will create
    $ deploy/site-shield/shield.sh plan sites/yourdomain.com.env
  3. 03 · Apply — bind the trap Worker, add decoy subdomains, wire the tunnel
    $ deploy/site-shield/shield.sh apply sites/yourdomain.com.env
  4. 04 · Verify — real pages untouched, trap paths answered by the sensor
    $ deploy/site-shield/shield.sh verify sites/yourdomain.com.env
  5. 05 · Remove — clean rollback, nothing left behind
    $ deploy/site-shield/shield.sh remove sites/yourdomain.com.env

FAQ

Will this slow down my site?
No. The Worker is bound to trap paths only. Requests for your real pages go straight to Pages and never execute it.
Do I need to change my site’s code or CSP?
No. Nothing is injected into your pages. Site Shield lives entirely at the edge and on the sensor.
Does it work if I’m not on Cloudflare Pages?
Yes, as long as the domain is proxied by Cloudflare. Trap routes are Worker routes on the zone, so the origin behind them doesn’t matter.
Can a real visitor get blocked?
Only a request for a trap path reaches the sensor. Nothing on your site links to those paths or to the decoy subdomains, so real visitors don’t land on them.
How do I undo it?
shield.sh remove deletes the Worker routes and decoy DNS records it created. Your site is exactly as it was before apply.

Related docs

More use cases
← Back to all use cases