Free surface check
Check your own app. Three minutes.
We look at what any visitor's browser downloads from your site: secret keys in your JavaScript (critical), published source maps and missing security headers (info). Your public Supabase key is expected and never counted. Every finding comes with a fix prompt for your AI coding agent; run the check again to prove it's fixed.
Your domain only. You prove you control it with a small file or a DNS record. We re-check that proof before every run.
This check doesn't log in, doesn't touch your database and doesn't follow links to other sites. We keep only the domain, the time and the result of each check. Privacy
Step 1 of 3Your app
Which domain?
Step 2 of 3
Prove it's yours.
Do one of these, then press the button below.
A. Add a file Easiest on hosted platforms
Publish a file at this address whose whole content is the code:
- Address
- Content
Or paste this into your AI tool and publish:
B. Add a DNS record
At your domain's DNS provider, add a TXT record:
- Type
TXT- Name
- Value
Some providers want only as the name. DNS changes can take a few minutes.
Step 3 of 3 · Surface check
Your app uses Supabase. We saw a Supabase project in your code. Its public (anon or publishable) key is meant to be public; what matters is whether that key can read your tables. The free check doesn't test that. The deep check will, at launch.
Get early access to the deep checkDeep check · invited
Your tables.
The deep check needs a second proof: that you control the Supabase project itself, not only the domain. You run one SQL statement that creates a read-only audit function. It returns your table structure, privileges and policies. It never returns rows, and only answers with a key that HullCheck holds.
Supabase dashboard → SQL Editor → paste → Run. Remove it when you're done with the statement shown at the bottom.
For every table, tell us who it's for. Readable tables with no answer stay review. Once you answer, anything beyond that is a fail, and you get the fix.
Prove it with two test accounts
Create two test accounts in your own app, A and B, each with at least one row in the tables above. Paste their access tokens (in your app: browser dev tools → Application → Local storage → the sb-…-auth-token entry → access_token). We act as A and try to read, change, delete and create B's rows.
This sends real writes. Only rows owned by test account B are targeted. If a policy is broken, one of B's test rows may be deleted and one test row may be created for B. Never use real users' accounts; a staging project is best. Tokens are used for this one run and never stored.
Done? Remove the audit function: