Can I put my API key in my website code?
Not a secret one. Everything a browser runs — HTML, JavaScript, CSS — is sent to every visitor, so a secret key pasted into a page is public the moment you publish, and minifying it or splitting it across three strings changes nothing. Some keys are meant to be there: vendors label those publishable or client keys, and constrain them so that being public is safe. If a secret key is already on a live page, rotate it at the vendor before you touch the page, because taking the page down does not un-publish what was already served.
Why a page cannot keep a secret
A browser has to receive everything it executes. That is not a gap in a particular host or framework, it is what serving a page means: a visitor's machine cannot run your code without being given your code. So the browser's own developer tools are enough to read whatever is in there, with no skill and no tooling required. Minifying, base64-encoding or assembling the key from concatenated fragments all survive precisely as long as it takes someone to look at the assembled value, which the network tab shows them anyway, sitting in the outgoing request.
So the distinction that matters is not hidden versus visible. It is between two kinds of credential, and the vendor names them for you. A publishable or client key is designed to live in a page — a payment provider's publishable key, an analytics measurement ID, a maps key locked to your domain. Those are public by design and fenced in on the vendor's side, which is why putting them in front-end code is correct rather than risky. A secret key is the other thing entirely: it usually carries the full authority of your account, so it can charge cards, read customer records, send email as you, or run up a bill against your API budget. Handing that to everyone who loads the page is the actual mistake, and "nobody knows this address yet" is not a defence, because scanners crawl newly published sites and public repositories continuously looking for exactly this.
If it is already live, rotate before you tidy up
The instinct is to delete the line and republish. Do the other thing first. Unpublishing does not recall what was already served: the old version can sit in a CDN edge cache, a search engine's cache, an archiving service, or a visitor's browser, and if the page lives in a repository the key stays in the commit history, where removing the line in a later commit leaves the earlier one perfectly readable. The only step that actually ends the exposure is invalidating the credential at the vendor, because the vendor is the one place the key has to be checked.
- Revoke or roll the old key so it stops working — creating a second key alongside it changes nothing.
- Issue a replacement and put it somewhere the page cannot read it, which in practice means server-side configuration.
- Read the vendor's usage or audit log across the exposure window and look for calls you did not make.
- If the key could move money or reach customer records, check for charges you do not recognise and follow the vendor's and your own obligations on telling anyone affected.
- Only then fix the page — and verify the fix by fetching the published page and searching the response for the old value, rather than trusting the editor.
Where the key goes instead, and what we found on live pages
The pattern that works is that the page never holds the secret at all. The page calls something you control, that thing holds the key and makes the outbound call, and the visitor's browser only ever talks to you. Often you do not have to run it yourself: a vendor's hosted widget or a hosted backend service is the server for this purpose. Whether you need more than that is a separate question, and does my website need a backend covers where the line actually falls.
Operating our own hosting taught us something counter-intuitive about this. AgentCeres — the AI Growth Officer at agentceres.com — hosts the pages its agents build for customers, and every one of those pages is served with a content-security policy that blocks the page from making any network request whatsoever. A key embedded in such a page cannot even be used by it: the code can run, calculate and navigate, and it has nowhere to send anything. That containment protects the visitor from the page, and it does nothing at all to hide the key from the visitor — which is the half people assume they are getting for free.
On 2026-09-17 we read through the pages customers had published and found one whose JavaScript assigned a payment provider's live secret key to a variable, with a customer's national ID number hardcoded into a lookup function further down the same file. Both were confirmed by fetching the live page rather than inferred from anything. Nothing exotic had happened: the owner pasted the key into a chat while asking for a feature that needed it, and it was written into the page. The rule that came out of that is the one worth taking away — never paste a live secret into a chat with anything that writes your page, a coding assistant included, because the natural thing for it to do with a key is use it where the code is.
The same review found the leak running the other way, which is worth knowing because almost nobody checks for it. Generated pages include login and sign-up forms when someone asks for a members area, even where no server exists behind them to log anyone in, and every form on such a page gets wired to a form handler — so a visitor who typed a password into one had it stored and emailed onward in plain text. In two September 2026 cases that included a real third party's email and password, arriving in the owner's inbox looking like an ordinary enquiry. We now recognise credential-shaped field names and strip those values before anything is stored, emailed or shown, and newly published pages make such a field non-submittable in the first place. The general lesson holds regardless of who built the page: it can leak in both directions, your keys outward and your visitors' passwords inward.
常见问题
- Is it safe to put a publishable or public API key in my website?
- Yes — that is what they exist for, and a front-end feature that needs one has no other option. Two things make it safe rather than merely permitted: the vendor limits what that key class can do, and you apply whatever restriction the vendor offers, usually a list of domains the key will answer for. Without the restriction a public key is still not dangerous to your account, but it can be used from someone else's site and billed to you.
- Can I keep the key private by putting it in an environment variable?
- Only if the code reading it runs on a server. This is the most common misunderstanding, because front-end build tools deliberately inline environment variables that carry the public prefix — NEXT_PUBLIC_, VITE_, REACT_APP_ and their equivalents — into the bundle at build time. The variable is private in your project settings and the value is baked into the JavaScript you ship, so it ends up in the page exactly as if you had typed it there.
- My key was exposed but the vendor shows no unexpected usage. Do I still have to rotate it?
- Yes. A quiet log tells you nobody has used it yet, not that nobody has it, and automated scanners routinely collect keys well before anything is done with them. Rotating costs minutes now and the alternative is an open-ended risk you cannot close by watching. Treat a clean log as good news about the past rather than as a decision about the future.