// last updated 2026-08-06

Security & trust

DenyFirst points a probe at a live backend, so the honest questions are: what are you allowed to touch, what do you actually read, and what happens to it afterwards. Here are the answers, in the same detail we'd want from a vendor pointed at our own database.

Authorization: we scan what you prove you own

A scan does not start because you typed a domain in a box. Before any probe runs, you connect the backend itself through the provider's own OAuth (Google for Firebase, the Management API for Supabase) and we confirm that the authorized account actually contains the project under test.

• Authorization is bound to the canonical backend project id, not to a domain. Controlling a domain has never been proof that you own the database behind it.
• The resulting grant is signed and time-limited. Read access expires in 30 days; anything that writes expires in one hour.
• Grants are verified again at the moment the scan runs, not just when it was requested. A revoked or expired grant stops work already in flight.
• If the artifact we extract points at a different project than the one you authorized, the scan refuses to continue rather than probing the wrong backend.

What we touch, and what we keep

The product has to prove that data is reachable. It does not have to read that data, and it doesn't.

• Reads are counted, not collected. On Firestore we request document names only (a field mask); on Supabase we use a count-only request. We learn that 4,000 records are reachable without receiving one of them.
• Writes are rolled back. The optional write check runs inside a transaction the database is asked to roll back, so it proves an insert would be accepted without leaving a row behind. If a server ignores that instruction, we delete the marked test row and verify it's gone. If we cannot, we say so in the report and hand you the exact statement to remove it.
• Sample identifiers are redacted before they reach a report, and never more than a handful.
• No customer records are stored. Reports contain counts, status codes, resource names and the fix, not your users' data.
• Any throwaway account a probe creates is deleted afterwards, and a failed deletion is reported as an operational note rather than quietly dropped.

Where scans run

Each scan executes in a disposable, hardened container that is destroyed when it finishes. The client artifact is fetched and unpacked inside that box, never on a shared machine. Outbound fetches are guarded against redirection to private or metadata addresses, pinned to a vetted IP, size-capped, and refuse to follow redirects.

Read-only is the default. Checks that authenticate or write are opt-in per scan and require a grant that explicitly permits them.

Responsible disclosure

If you believe you've found a vulnerability in DenyFirst itself, please tell us before you tell anyone else, and we'll work the problem with you.

• Email security@denyfirst.com with enough detail to reproduce it.
• We aim to acknowledge within 2 business days and to give you an assessment and a fix timeline within 10 business days.
• We will not pursue or support legal action against anyone acting in good faith under this policy: testing only against your own account, no privacy violations, no service degradation, and no access to data that isn't yours.
• Please give us reasonable time to ship a fix before publishing. We'll credit you if you'd like to be credited.

The same courtesy runs the other way. If a scan of your app surfaces something serious, it goes to you, not to a blog post. We don't publish findings about a customer's app, and we don't use one customer's incident as marketing for the next.

What we don't claim

A scan is evidence of reachability at a point in time. It is not a certificate, and a clean result is not a guarantee that your app is secure.

• We check access control on Firebase and Supabase backends. We are not a substitute for a full penetration test, code review, or dependency scanning.
• A collection that is genuinely meant to be public will be reported as public, and only you can confirm the intent. We label it rather than pretending to know.
• Firebase write checks are not yet implemented and are reported as untested rather than as passing.
• Where we could not obtain the principal needed to test something, the report says untested. Silence is never presented as a pass.

Contact

Security matters: security@denyfirst.com
Everything else: hello@denyfirst.com