Public and secret

Try this on Le Monde: right-click the main headline, choose Inspect, and type a headline of your own in its place. The page now shows your news, but you haven't hacked anything. You have edited your own copy of the page, in your browser's memory, and Le Monde's server never knew. A reload brings the real headline back.

That works the other way too. Everything a site sends to your browser is now on your computer: the HTML, the JavaScript, the prices, the hidden fields, and any key the code uses. "View source" and the developer tools let anyone read it and change it. Scrambling or compressing the code changes nothing, because the browser has to understand it, so a patient person can too. An internal tool is no exception: every employee can open it, links get forwarded, and the code often sits in a shared repository as well.

So the line is easy to draw. What the visitor may see and change can go to the browser. Secrets, and the rules that protect money and data, stay on a server the company controls.

A colleague has built a small tool with an AI agent that sends appointment reminders by SMS. It works, and the SMS service's secret key sits right there in the page's JavaScript. Whoever copies that key can use the service as your company: send thousands of messages in your name, on your bill.

The fix is to move the key to a server. The page stops calling the SMS service itself. Instead, it calls a small back-end function that the company runs, which checks who is asking, adds the key, talks to the service and sends back only the result. The key never leaves the server. Be wary of "we put it in an environment variable", a setting kept outside the code: if the code that uses it runs in the page, the value gets copied into the page anyway.

Two more steps come before anyone uses the tool. A key that has been in a page, or in the project's history on GitHub, may already have been copied, so revoke it and create a new one. And protect the new function too: logged-in staff only, a limit on requests, a spending cap at the service.

Not every key is a secret. Some are made to sit in the page, because the browser needs them to talk to a service directly. They tell the service which project is calling, a bit like the account number printed on an invoice, and they give no power on their own.

Payment providers show the difference clearly. Stripe, which handles payments for many sites, gives you two keys. The publishable one, starting with pk_, lets the payment page start a payment. The secret one, starting with sk_, can move money and read customer data, so it lives only on your server. A map shown in a page loads in the visitor's browser, so its key is visible to everyone. A Firebase project's configuration, apiKey included, is also meant to be in the page.

Public keys like these are protected at the service: a map key is restricted to your own domain and given a quota, and a Firebase database has security rules. So when someone finds a key in a page, the first question is what kind of key it is. The provider's documentation answers that in a minute.

A key says who is calling. Rules decide what the caller is allowed to do, and they live at the service or on your server, out of the visitor's reach. In Firebase, they're the security rules: "only the owner can read this booking", "only staff can change prices". For a map key, it's the list of domains allowed to use it and the daily quota. On a server you run, it's the checks in the back end.

That's where the risk usually hides. AI agents and tutorials often start a Firebase project in "test mode", where anyone on the internet can read and change the whole database, and nobody comes back to close it before launch. The key in the page looks alarming, but the open rules are what leak the data.

So don't settle for anyone's word, including the developer who set it up. Ask for a test: someone logged out, or calling from another site, tries to read or change data they shouldn't reach. If it works for them, it works for anyone, and the launch waits until the rules are fixed.

You don't need to read the code to ask these.

Before a tool or an app goes live, ask the team to list every key it uses and say, for each one, whether the provider's documentation calls it publishable or secret. Ask where each secret key is stored, and expect "only on the server" as the answer. If a secret ever sat in a page or in the code's history, ask whether it has been revoked and replaced. Ask what protects the data: the database rules, the domain restrictions, the request limits and the spending caps. Ask what the tool sends to outside services, especially personal data such as customer emails, and whether that has been checked for GDPR.

Then ask to see it fail: a logged-out test that tries to read or change something it shouldn't. A team that has done this work can show you in minutes.