How to Protect API Keys in a React or JavaScript Website

If you are building a React or JavaScript website that calls an external API, one rule matters immediately: a secret API key should not be treated as secret once it is sent to the browser.

Anything delivered to the browser can potentially be inspected by the user. That means putting a private API key inside React code, frontend environment variables, or a bundled JavaScript file does not make the credential private.

Quick Answer

If an API requires a private key, use this general architecture: browser calls your server or serverless function, and your server or serverless function calls the external API. The private key stays on the server. The browser calls your backend endpoint instead of receiving the private credential.

Why Frontend API Keys Are Exposed

React and JavaScript applications execute in the user's browser. The browser needs the application's JavaScript files to execute the website. Therefore, anything included in those files can potentially be inspected by the user. This includes JavaScript code, bundled configuration, public environment variables, API URLs, and client-side tokens.

Environment variables are useful for configuration. They are not automatically secret. If a value is included in a client-side production bundle, assume users can access it.

The Unsafe Pattern

A common pattern looks conceptually like: the browser sends a request directly to an external API with a private API key. The browser must receive the key to make the request. That means the key is no longer private.

The Safer Pattern

Use: browser calls your backend, and your backend calls the external API. The browser sends the request to your server. Your server securely retrieves the API credential. The server calls the external service. The server returns only the information the browser needs.

What About Public API Keys?

Not every API key is necessarily a secret. Some services intentionally use publishable client-side keys with restrictions. The important question is: what does the API provider say the credential is designed for? If a credential grants sensitive access, treat it as a secret. If a provider explicitly documents a browser-safe public key, follow its current security guidance.

Environment Variables Are Not Magic

You may see code such as process.env.API_KEY or a framework-specific environment variable. That does not automatically mean the value is private. The key question is: where does this value end up? If the framework embeds it into client-side JavaScript, users can inspect it. Use server-side environment variables for secrets.

What If the Key Is Already Exposed?

If a private API key has already been included in a public website, assume it may have been copied. Do not simply remove the key from the source code and assume the problem is solved. Take the appropriate remediation steps recommended by the API provider, which may include revoking the exposed key, creating a replacement, reviewing usage, restricting permissions, and updating the application.

The exact process depends on the service.

Add Backend Controls

A backend proxy should not simply hide the API key. It should also enforce appropriate controls. For example: authentication, authorization, input validation, rate limiting, request limits, logging, and error handling. Otherwise, an attacker may simply abuse your backend endpoint instead of stealing the original API key.

Protect Your Repository

Do not commit private credentials into Git repositories. Use environment variables, secret-management systems, and deployment platform secret configuration. Also check whether the credential has already appeared in Git history, build logs, CI output, public repositories, or client-side bundles.

React Deployment Checklist for API Keys

Before deploying: identify every credential, determine which credentials are public, determine which credentials are private, remove private credentials from frontend code, store private credentials server-side, rotate credentials that were exposed, review backend permissions, test the production application, and check the final JavaScript bundle for accidental secrets.

FAQ