IDs can ship. Keys cannot. Know which is which
A GA4 measurement ID, a Meta Pixel ID, a Supabase publishable key are designed to sit in the browser. A Resend key, a service-role key, a bot token are not. The model does not distinguish; both are "strings the code needs." The Supabase publishable key is only safe because row-level security is supposed to be doing the work behind it.
Where it bit
The good case: blinkz-site. GA and Pixel IDs hardcoded on purpose; the Resend key only ever via wrangler secret put; zero key hits in 50 commits. The bad case in the research: a service-role JWT in the bundle, found by fetching the JS and pasting the token into jwt.io.
The practice
Keep a two-column list per project: ships to the browser, never leaves the server. Legacy Supabase anon and service_role keys are deprecated at the end of 2026; move to sb_publishable_ in clients and one sb_secret_ per backend service.
Check it
curl -s https://YOURSITE/_next/static/chunks/*.js | grep -oE "eyJ[A-Za-z0-9_-]{30,}\.[A-Za-z0-9_-]{30,}" | head -3
# paste one into jwt.io; "role": "service_role" means the browser owns the databaseGet this check as a script you can run tonight
What to do with this
If you run a business on something AI built and the checks came back with more than you expected, that is worth a conversation.
We do a free 30-minute Health Check for service businesses that want to know exactly where their biggest leaks are. No slide deck. No pitch. We ask questions, find the gaps, and tell you what we see. If there is no obvious fix, we will tell you that too.
Blinkz finds what is broken in how a business runs, then fixes it. AI only where it earns its place.