Why You Can't Put an API Key in the Frontend

Frontend and backend, in one sentence each

The frontend is everything downloaded and run inside your visitor's own browser: the HTML, CSS and JavaScript that draws the screen and reacts to clicks. The backend is code that runs somewhere else entirely, a server your visitor never connects to directly, only through requests the frontend sends it. This site's own guide to what a frontend and backend actually are covers that split in full; this page assumes it and covers why the split exists in the first place, and what actually breaks when it's ignored.

What a visitor can actually see, not just in theory

Open any live website, press F12 (or right-click and choose Inspect), and two tabs make the whole rule concrete rather than abstract. View Page Source shows the exact HTML and JavaScript sent to the browser, in full, the same way you'd read any text file. The Network tab shows every request the page makes as it loads and as you interact with it, including the complete URL and any parameters or keys sent along with it. Nothing that travels this route stays private. A key typed directly into a frontend component, however deeply buried in the code, sits in that same downloadable, readable file, findable by anyone who thinks to look, not just a determined attacker.

This is worth actually trying once, not just reading about. Open dev tools on any site you use daily, watch the Network tab as a page loads, and the abstraction stops being abstract.

Why this makes a client-side secret a real, exploitable bug

An exposed API key isn't a style violation, it's a working credential handed to every visitor. Depending on what that key unlocks, the consequence ranges from someone quietly running up your usage bill on a paid API, to something far worse. The sharpest version is a payment secret. A payment gateway uses a secret to sign payment requests and to check its payment notifications: PayFast, for example, uses your passphrase once you've set one. If your site creates the signature in the browser, the secret ships to every visitor inside the frontend code, readable the same way as any other exposed key. Anyone who found it could sign a valid-looking payment confirmation and try to mark an unpaid order as paid. If it works, that is a direct financial loss, not a hypothetical one. Our guide to adding a payment gateway to your website shows which keys belong where.

The same mechanism repeats outside payments too. A discount-code check written entirely in frontend JavaScript can be read, understood and bypassed by anyone willing to look at the page's own source. A client-side "is this user an admin" check can be edited in the browser's own dev tools before the request is even sent. In every case, the fix is identical: move the decision, and whatever secret it depends on, to the backend, where the visitor's browser genuinely cannot reach it.

Which keys are actually fine in the frontend

Not every key needs this treatment, and treating all of them identically just makes a real project harder to build for no security benefit. A key that's specifically designed to be public, is rate-limited by whoever issued it, and can only read data rather than write, charge or delete anything, is safe to ship in the frontend, a Google Maps display key is the standard example. The test that actually matters: what happens if a stranger copies this value right now? If the answer is "they can view a map" or "they can read the same public data any visitor already sees," the frontend is fine. If the answer touches money, personal data or account access in any way, it belongs on the backend without exception.

Where the backend code lives in an AI-built project

The rule is the same on every AI website builder; only where the server code lives changes. Builders call these server functions, edge functions or backend functions, and many set them up for you as soon as you add a database or logins. Some make only the page, with no server at all until you connect one, and until then there is nowhere safe to put a secret. Ask your AI coding agent: "Where does my project's server code run, and where does it keep secrets?" If the answer is "in the page", don't put a secret there; ask it to set up a backend first.

Putting the secret in backend code is most of the job, but it isn't automatic proof of safety on its own. A secret read inside a backend function still needs to come from an environment variable or the platform's own secrets manager, not be typed directly into that same server-side file as a literal value. The file being server-side stops your visitor's browser from ever seeing it; it doesn't stop a leaked repository or a shared screen from exposing a value hardcoded in plain text.

Checking whether your own project already got this right

Search your project's own frontend files, everything outside the backend folder your platform uses, for the literal name of any secret, API key or credential your project depends on. A real match means it's exposed and needs to move to a backend function, read from an environment variable there instead. Finding nothing is a good sign, though not a complete guarantee on its own, since a key could also be assembled or encoded in a way a plain text search misses. Genuinely uncertain about a specific piece of your own project's setup, describing exactly which value and which file to this site's Custom Prompt Builder turns that uncertainty into a precise, answerable prompt.