DenyFirst blog
A security scanner that refuses to run
Most of what DenyFirst does is send ordinary requests to a backend and notice which ones come back with data they shouldn't. That's a useful thing to point at your own app. It's a dangerous thing to point at someone else's. The distance between those two is a single question — *do you own this?* — and the entire product is built around refusing to proceed until that question is answered.
It would be easier to skip. A free-text "domain" box, a Scan button, results in thirty seconds. Every competitor demo is smoother for it. We think that smoothness is exactly the tell of a tool that will eventually be used against someone.
Owning a domain is not owning the backend
The obvious ownership check is "prove you control the website." It's also not enough. What a domain *references* is not the same as who owns the referenced backend. A site can point its client at a Firebase project or a Supabase instance that belongs to a different account entirely. Verifying the domain would authorize a scan of infrastructure the verifier doesn't control.
So DenyFirst binds authorization to the backend project itself, not the website:
- Firebase / Google Cloud, Supabase: you authorize through the provider's own
OAuth. We confirm the authorizing account actually *contains* the project under test — by listing the projects it can access and matching the one you named. The provider is the source of truth for who owns what.
- Your own website (Next.js, WordPress): you publish a one-time token on the
domain (a DNS record or a file). Here the domain *is* the asset, so domain control is the right proof — and it grants a read-only, website-only scan, never write access.
Either way, the scan gate checks a signed grant bound to that exact project before a single request goes out. No grant, no scan. There is no --assume-ownership escape hatch on a hosted seat.
Why this is the whole business, not a feature
We sell a tool that finds open doors. The only thing separating that from a tool that *walks through* open doors on the internet's behalf is the ownership gate. So we treat it as load-bearing:
- Grants are integrity-protected, so a database compromise can't mint or widen the
right to scan something.
- Scans run read-only by default from disposable sandboxes; any escalation (minting
a throwaway test user, writing a canary record) happens only when the owner explicitly enables it, and is cleaned up afterward.
- Abuse detection watches for the signature of misuse — one account trying to reach
many backends it can't prove it owns.
None of this makes the demo faster. All of it is the reason you can run the thing against your production app without wondering what else it's touching.
Refusing to run is a feature
There's a version of this product that scans anything you type in. It would convert better on cold traffic and it would, sooner or later, be in the news for the wrong reason. We'd rather lose the impatient signup than build the tool that gets abused.
When DenyFirst comes back and says *"ownership not verified — I won't scan this,"* that isn't the product failing. That's the product working exactly as designed.
DenyFirst proves you own a backend, then audits its access control read-only and hands you the exact fix. Owned, permissioned, and honest about what it touches. See how it works →
← All posts