I wanted deny rules for common leak paths — not a zip of someone’s secrets

I kept seeing the same uncomfortable class of deployment mistake: a production host that still answers for .git, .env-shaped paths, source maps, or an old backup archive.

The useful question is usually not “can I retrieve something interesting?” It is “are these paths reachable on a site I control, and what can I put in front of them before the next deploy?”

So I built LeakDeny: paste a URL you control → run a proof-style check → pay once → download a deny pack for common exposure paths. The pack is $29 one-time.

What the pack is for

LeakDeny is deliberately narrow. It gives you host-level snippets and verification steps for patterns such as:

• .git and similar repository paths
• .env-shaped paths
• JavaScript source maps (.map)
• backup archives and database dumps
• a few common backup-file patterns

Before any of that, check your own site for free. This status-only script requests ~18 well-known debris paths, peeks at the first 64 bytes in memory to separate real files from soft-404s, and never prints or saves response bodies:

curl -fsSLO https://raw.githubusercontent.com/dimonch-byte/leakdeny-check/main/check-exposed-paths.sh
bash check-exposed-paths.sh https://your-site.example

Repo + free one-server nginx/.htaccess starter snippets: https://github.com/dimonch-byte/leakdeny-check

The intended workflow is boring, which is good: review the generated rules, apply them in the layer you actually operate, reload or redeploy, and verify that the paths return a denial response rather than 200 OK.

For example, the check after deployment should be something like:

curl -sI https://your-domain.example/.git/HEAD
curl -sI https://your-domain.example/.env

The exact status and routing depend on your host, proxy, CDN, and configuration. A 404 or 403 can be the desired result, but it is not proof that a file was never exposed in the past.

What it does not do

• It is not a WAF.
• It is not a bug-bounty scanner for strangers’ domains.
• It does not remove a secret that was already committed or downloaded.
• It does not rotate credentials for you.
• It does not claim that a few deny rules equal a complete security review.

If a credential may have been exposed, rotate or revoke it separately. Blocking /.env today does not make an old leaked token safe. Likewise, a deny rule is only useful if it is actually applied at the right layer and tested after a CDN or framework change.

I also made a conscious decision about the proof asset: LeakDeny never packages secret contents. The example gist contains path rules only. I would rather publish a small, reviewable configuration fragment than turn a security check into a mechanism for collecting or redistributing someone’s data.

Try it

• Free check script
• LeakDeny — exact-path pack, $29 once

Use it on a URL you own or are authorized to test. The paid pack supports Apache/.htaccess and nginx directly, with manual snippets for Vercel and Netlify. On other hosts (Caddy, Cloudflare rules, managed platforms) the free starter snippets show the intent, but LeakDeny will tell you it's unsupported before you pay.