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

The public example gist has nginx and Caddy versions:

See the example deny snippets

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

• LeakDeny
• Example nginx/Caddy gist

Use it on a URL you own or are authorized to test. If your stack is Cloudflare, a managed host, or something other than nginx/Caddy, treat the pack as a starting point and translate the intent into the controls your platform actually supports.