Home › Blog › Secrets · Guide

API Keys in Front-End Code: Which Are Safe and Which Are Not

API keys appear everywhere in modern web apps, but not every key is meant to be exposed. Understanding which keys can live in front‑end code and which must stay secret prevents accidental data leaks and reduces the attack surface of AI‑generated projects.

Keys Designed for Public Use

Some services provide keys that are intentionally publishable because they rely on server‑side policies to enforce security. The Supabase anon (publishable) key, Stripe publishable keys that start with pk_live_, and the Firebase web app configuration fall into this category. These keys enable the client to call APIs, but the actual data access is governed by rules such as Row Level Security in Supabase or Firebase security rules.

However, developers must still verify that the associated server‑side policies are strict enough to block unauthorized reads or writes. For example, a Supabase anon key should only allow reads on tables that have RLS enabled, and a Firebase config should rely on security rules that limit data exposure based on authentication state.

• Supabase anon (publishable) key
• Stripe publishable keys (pk_live_…)
• Firebase web app configuration

Keys That Must Never Be Public

Any key that provides full control over a service must stay out of the browser. This includes the Supabase service_role key, Stripe secret keys that begin with sk_live_, database connection strings, AI provider API keys, webhook signing secrets, and private signing keys. These credentials give the holder unrestricted read and write privileges, often bypassing any server‑side checks. If they appear in front‑end code, an attacker can harvest them directly from the bundle or via the network console.

The result is that a malicious user can extract the key, impersonate the service, and potentially exfiltrate data, issue fraudulent transactions, or compromise downstream systems.

• Supabase service_role key
• Stripe secret keys (sk_live_…)
• Database connection strings
• AI provider API keys
• Webhook signing secrets and private keys

Inspecting the Built Bundle for Leaked Secrets

After building the application, open the generated JavaScript bundle and search for patterns that resemble secret keys. Common indicators include long alphanumeric strings, prefixes like sk_live_ or service_role, and URLs that contain authentication tokens. The browser’s Network tab can also reveal secrets sent in requests, especially if a key is accidentally placed in a query parameter or request header.

Running an automated secrets scanner across the repository adds another safety net. Scanners compare code against known secret patterns and flag any matches. Even if a secret is hidden inside a minified file, the scanner can still detect the characteristic prefix or length. Combining manual bundle inspection with automated scanning provides confidence that no privileged keys have slipped into the client side.

The Rotate‑First Rule for Leaked Secrets

If a secret is discovered in the client bundle, the first action is to revoke or rotate it before making any code changes. Rotating the key invalidates the compromised credential, preventing attackers from using it while the developer works on cleanup. After rotation, remove the secret from the source code, delete it from version‑control history, and replace it with a proper server‑side reference or environment variable.

Rotating first also avoids a race condition where an attacker could exploit the key before the developer patches the code. Once the old key is disabled, the new key can be safely added to the back‑end where it never reaches the browser. This disciplined approach limits exposure time and reduces the chance of accidental reuse of the compromised credential.

Restricting Browser Keys When Possible

Many providers allow additional restrictions on publishable keys to tighten security. For example, Google Maps API keys can be limited to specific HTTP referrers, and some services let you define allowed API endpoints for a given key. Applying these constraints ensures that even if a public key is harvested, it cannot be used from an unauthorized domain or for unintended operations.

Implementing referrer restrictions or domain whitelists is a lightweight mitigation that complements server‑side rules. It adds a layer of defense without requiring code changes, because the restriction is enforced by the provider. Review each provider’s documentation to see which restrictions are available and configure them as part of the deployment process.