The Keys & Secrets Sorting Drill
Some of your keys are meant to be public. Some are meant never to be seen. They look identical and they sit in the same file.
Moving a key is not fixing it. Once a value has been somewhere reachable, taking it out removes it from today — not from history.
one-time · instant download · yours to keep
01 — The problem
Two strings of gibberish. Opposite rules. No way to tell.
Nothing about the string tells you
One key is designed to ship in the page where anybody can read it. The other must never leave your server. They are the same length, the same shape, and they arrived in the same setup step. Only the documentation of whatever issued them says which is which.
So people guess, and guess both ways
Half the founders hide a publishable key and break their own app. The other half ship a secret one and never find out. Neither mistake announces itself, because the app works fine either way until somebody looks.
And the clean-up does not clean up
You find one in the wrong place, move it, and feel better. That is the moment this drill exists for. The value was readable while it sat there, and moving it does not change what was already read.
02 — What's inside
Four questions per key. Never the key itself.
Which kind it is
Publishable or secret — the one answer that is not in your project at all. It is in the documentation of whatever issued the key, and it takes about a minute to look up.
Where it lives, and where it has been
Server settings, a private repo, the browser bundle, a public repo, a screenshot in a thread — and separately, whether it has ever been anywhere reachable.
Whether it has been rotated
Have you issued a new value and retired this one since then? This is the only answer that can clear a key that has already been out.
You are entering names and four answers, never values. There is nowhere in the sheet to paste a key and nothing in it connects to anything, which matters more here than anywhere else in the line.
03 — The standard
Three rules it will not bend for you.
Relocation is not remediation
A secret that has ever been reachable reads ROTATE NOW even when it now sits in exactly the right place. Move it wherever you like on the sheet and watch the answer not change. The only thing that clears it is issuing a new value and retiring the old one — this is the one answer in the whole line that a tidy-up cannot release.
A publishable key in the browser is not a finding
It is the key doing its job. Those rows read MEANT TO BE PUBLIC and are never counted against you, because a tool that tells you to hide them is teaching you to distrust its own output — and the next time it flags something real you will click past it.
An answer you could not find is scored as the worst it could have been
Not a guess about what is likely — the worst, because an answer you cannot produce is not evidence. Stated that way it also cannot be gamed: writing cant_find can never get you a better result than telling the truth would have. Where an unfound answer could not have changed the row either way, it is not counted against you and the row says so.
04 — How it works
An hour, and a habit you keep.
01
List every key your project uses, by name. Environment settings, config files, anything you pasted into a setup screen once and forgot.
02
Look up which kind each one is in the documentation of whatever issued it. This is the answer that is not in your project, and it is the one that decides everything.
03
Answer where it lives, whether it has ever been reachable, and whether it has been rotated. Answer cant_find honestly where you have to.
04
Rotate what needs rotating before you move anything. Moving first feels productive and changes nothing.
05 — What you'll see
The worked example, live.
Ten keys from a typical first app. Try moving K-02 to wherever you think is safest — it stays ROTATE NOW until you say it has been rotated. And compare K-04 with K-05: both sitting in the browser bundle, one of them completely fine.
Try it on the worked example
Ten keys from a typical first app. Try moving K-02 anywhere you like — it stays ROTATE NOW until you say it has been rotated. That is the whole point of it.
| Key | Class | Lives now | Ever public | Rotated | Destination |
|---|---|---|---|---|---|
K-01 Database service key | SAFE WHERE IT IS this is a secret in your server environment, which is where it belongs | ||||
K-02 Email sending API key | ROTATE NOW this is a secret that has been reachable before and has not been rotated since - it now sits in your server environment, and moving it did not un-publish it | ||||
K-03 Payment processor secret key | SAFE WHERE IT IS this is a secret in your server environment, which is where it belongs | ||||
K-04 Database public API key | MEANT TO BE PUBLIC this one is published on purpose - it is designed to ship in the page, which is what publishable means | ||||
K-05 Analytics write token | ROTATE NOW this is a secret and it is shipped in the browser bundle, so anybody can already read it | ||||
K-06 Deployment token in .env.example | MOVE IT this is a secret committed to a private repository - not public, but more people can reach it than should, and it stays in the history | ||||
K-07 Payment processor publishable key | MEANT TO BE PUBLIC this one is published on purpose - it is designed to ship in the page, which is what publishable means | ||||
K-08 Old admin token from the first build | ROTATE NOW this is a secret and it is shipped in the browser bundle, so anybody can already read it | ||||
K-09 Map tile key | SAFE WHERE IT IS this is a secret in your server environment, which is where it belongs | ||||
K-10 AI provider key pasted for help | ROTATE NOW this is a secret and it is pasted into a chat or a screenshot, so anybody can already read it |
Verdict
KEYS BURNED
At least one secret has been reachable. Rotating is the only thing that helps.
Fix first K-08 — this is a secret and it is shipped in the browser bundle, so anybody can already read it
5 of 10
keys that need work
50% of the keys listed
3
anybody can read right now
sitting somewhere reachable today
1
tidying up will not fix
only a rotation clears these
2
told to leave alone
published on purpose
None of the four numbers above changes the verdict. Keys that read MEANT TO BE PUBLIC are never counted against you, and nothing here ever asks for a key's value.
This is the live engine. 60 rows, the same formulas, in a file you keep Start Here tab that explains every answer in plain words Dashboard with the verdict, the counts, and what to fix first
Get the kit — $4906 — Who it's for
For the person who was handed four keys and no instructions.
Buy this if
- You have keys in a project you built with an AI tool and cannot say which are which.
- You have pasted a key into a chat to get help with an error.
- You once found a key somewhere it should not be, moved it, and moved on.
- You are about to make a repository public and want to check something first.
Skip it if
- You manage secrets for a living. There is nothing here you do not know.
- Your project has no keys in it yet.
- You want something that searches your code for keys — this is a sorting drill, not a scanner.
What this is not
It never asks for the value of a key and there is nowhere to paste one. It connects to nothing and sees no part of your project. It grades how keys are handled and never a person. It is not a secret scanner, a penetration test, or a security audit, and it is not legal advice — it reads back what you tell it, using rules you can see in the formulas.
07 — Works alongside
Where this sits.
This one is the credentials themselves. The three below are the idea it comes from, the place a leaked key does the most damage, and where to take what you find.
The Browser Line Read-Off
$59The keystone of the same line. A key in the bundle is the purest case of the idea it teaches — anything you handed the browser, you handed everyone.
The Supabase RLS Read-Off
$69The database layer. Its single hardest question — is the secret key reachable from the browser — is one row on this sheet, worked out properly.
Vibe-Coded App Pre-Launch Security Gate
$79The launch-moment go/no-go across six controls. One of them is secrets out of the client bundle and repo; this is how you answer it from evidence.
08 — Common questions
Before you buy.
No, and you should not. The sheet asks for a name and four answers per key — what kind it is, where it lives, whether it has ever been reachable, and whether it has been rotated. It never asks for a value and there is nowhere to paste one. Nothing here connects to anything, so there is nothing to leak.
No, and the drill says so out loud. Publishable keys are designed to ship in the page — that is what publishable means, and hiding them would break your app. Those rows read MEANT TO BE PUBLIC and are never counted against you. The problem is that a publishable key and a secret one look identical, sit in the same file, and only the documentation of whatever issued them tells you which is which.
Because moving a key is not fixing it. Once a value has been somewhere reachable it has been read — by a crawler, a fork, a log, a person who has since left. Taking it out of the bundle removes it from today, not from history. The only thing that clears that mark is issuing a new value and retiring the old one. This is the one answer on the sheet that tidying up cannot change.
Anywhere outside your own server that somebody could have read it. A bundle you later cleaned up. A repository you later made private. An old commit still in the history. A screenshot in a support thread. If the value was ever visible to someone who is not you, the honest answer is yes — and if you cannot tell, say so and the sheet will assume the worst.
It is scored as the worst answer that question could have had — not a guess about what is likely, the worst, because an answer you cannot produce is not evidence. Stated that way it also cannot be gamed: writing cant_find can never get you a better result than the truth would have. Where an unfound answer could not have changed the row either way, it is not counted against you and the row says so.
No. A scanner searches your code for things that look like keys and tells you what it found. This does the opposite job: you already know your keys exist, and what you cannot tell is which ones were ever supposed to be hidden and which have quietly stopped being secret. It grades how keys are handled, never a person, and it is not a penetration test or a security audit.
Get the Read-Off
Find out which of your keys were never secret.
- One .xlsx — Start Here, Dashboard, Drill
- 60 rows with dropdowns and live formulas
- A worked ten-key example, already filled in
- Never asks for a key value — nothing to leak