Coding with AI
Why an AI API key must stay server-side
Keep model provider credentials out of browsers and mobile bundles with a controlled backend and usage limits.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
No. Anything shipped to a browser can be read and reused by the user or an attacker. Call the AI provider from a backend that authenticates your user, validates requests, enforces budget and rate limits, and stores credentials in a secret manager or server environment.
What this means in plain English
Browser code is sent to the user, so anything inside it can be read. Hiding or scrambling an AI API key in JavaScript does not make it private. Keep the provider key on a trusted server.
Your server should identify the user, check request size and allowed actions, apply spending and rate limits, then call the AI provider. Rotate any key that was ever shipped publicly.
Can frontend code keep a long-lived secret?
| Client | Public code and short-lived user/session tokens only |
|---|---|
| Backend | Provider credential and policy enforcement |
| Abuse control | Per-user limits, logging and revocation |
A simple example
A website calls the model provider directly with a key in its bundle. Somebody copies it and sends thousands of requests outside the site. Moving the call behind an authenticated server endpoint lets the owner limit each account and revoke abuse.
What to do, step by step
1. Remove provider keys from bundles and history.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on client: public code and short-lived user/session tokens only. Write the result down so you can compare it later.
2. Create an authenticated server endpoint.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Validate input size and allowed operations.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Rotate exposed keys and monitor usage.
Finish by checking the result against abuse control: per-user limits, logging and revocation. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Do not log full authorisation headers or sensitive prompts. Logging should help with cost and errors without creating a new copy of private information.
Common mistakes and how to avoid them
Obfuscating a key in JavaScript.
This gives a misleading or unsafe result because it leaves out client. A better approach is to remove provider keys from bundles and history, then check the result before making the change permanent.
Relying on provider referrer checks alone.
This gives a misleading or unsafe result because it leaves out backend. A better approach is to create an authenticated server endpoint, then check the result before making the change permanent.
Logging authorization headers.
This gives a misleading or unsafe result because it leaves out abuse control. A better approach is to validate input size and allowed operations, then check the result before making the change permanent.
Words explained
- API
- A defined way for one program to send requests to another program or service.
- API key
- A private credential that lets software use an API. It must stay on a trusted server, not inside public browser code.
- token
- A small piece of text counted by many AI services when measuring input and output usage. It can also mean a login credential in other contexts.
- rate limit
- A rule that limits how many requests somebody can make in a period of time.
Quick checklist
- Remove provider keys from bundles and history.
- Create an authenticated server endpoint.
- Validate input size and allowed operations.
- Rotate exposed keys and monitor usage.
Common questions
What is the simple answer?
No. Anything shipped to a browser can be read and reused by the user or an attacker. Call the AI provider from a backend that authenticates your user, validates requests, enforces budget and rate limits, and stores credentials in a secret manager or server environment.
What should I check first?
Start with client: public code and short-lived user/session tokens only. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Remove provider keys from bundles and history. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Obfuscating a key in JavaScript. Avoiding that one mistake makes the rest of the comparison much more trustworthy.