Built with v0
A prefix decides who can read your keys.
v0 writes React and Next.js, and Next.js has one rule about which values reach the browser. It is a naming convention, and it is enforced at build time without asking.
The quotes below are from the Next.js documentation, linked. Nothing about the framework is broken — the prefix does exactly what it advertises, to whatever you attach it to.
v0 is a trademark of its owner. This page quotes public documentation to explain a scope of work. There is no partnership, endorsement or affiliation in either direction.
What stays yours
Where the generator stops.
v0 produces components and the code around them. These are the decisions it cannot take for you.
Which variables carry the public prefix
Next.js is explicit: a prefixed value “will be inlined into any JavaScript sent to the browser”. Written into the file itself — not hidden, not revocable later.
Noticing that a rebuild froze the value
The surprise: “all NEXT_PUBLIC_ variables will be frozen with the value evaluated at build time”. Rotating a key does not change what a built page hands out.
Keeping the server-only values server-only
Unprefixed variables “are only available in the Node.js environment, meaning they aren’t accessible to the browser”. That boundary holds until somebody adds a prefix to make an error go away, at which point it silently stops holding.
Whatever the generated component is allowed to ask for
v0 writes the interface. What the interface is permitted to request, and whether the thing answering it checks who is asking, is a decision that lives on your side of the network call.
Check it tonight
Read your own bundle.
Every one of these is something a visitor could already do to you. Doing it first costs nothing.
List every variable carrying the public prefix
Open your environment settings and read the names. Each prefixed one is a value you have decided to publish. Ask of each: would I paste this into a public forum?
Search your built bundle for the values themselves
Load your live site, open the JavaScript it downloads, and search for the key text rather than the variable name. Inlining replaced the name with the value, so the name will not be there.
Check whether a rotated key actually rotated
If you have ever replaced a key, compare what your live page serves against what your dashboard says is current. A build made before the rotation is still serving the old one.
Call your own API without being signed in
Take one request the app makes while logged in and repeat it with the session removed. If it answers, the check protecting it was in the interface.
Finding your own key in your own bundle is not a small result. It is the finding. For everything a bundle cannot show you, there is the free prompt.
What a read adds
A leaked key is the cheap one.
The four above catch a key you published on purpose and a stale build still serving an old one. They cannot tell you that an endpoint accepts an id from the browser and returns whatever it names, which is the finding that costs you customers rather than a key rotation.
A key you can rotate. A door you did not know was open, you cannot. The standard the read runs against is published, limits included.
€350 + VAT · 48 hours
An independent pass over your app.
Your repository and your live app, every finding with the evidence, what it costs you and a prompt you can paste back into v0.
€430.50 including VAT.
Start here
Send me the five questions.
They take about four minutes. If the answer is that your app does not need this yet, that is the answer you get.