How to Hide API Keys on a Website
If your website uses third-party APIs, the biggest mistake is placing secret keys in front-end code where anyone can inspect them.
This guide explains how to hide API keys on a website using proven server-side patterns, safer proxy designs, and environment-based storage.
API security is not only about secrecy; it is also about limiting what a leaked key can do.
The best approach depends on whether the key is public, secret, or tied to a user session, and that distinction matters more than most developers realize.
Why API keys should not live in client-side code
Anything sent to the browser is visible to users and automated scanners.
That includes JavaScript bundles, source maps, network requests, local storage, and even configuration values embedded during build time.
If a secret API key is exposed in the front end, attackers can:
- Send requests from their own systems and impersonate your application
- Consume your API quota and create unexpected costs
- Access sensitive data returned by the provider
- Abuse permissive endpoints to enumerate records or trigger actions
Many services distinguish between public and secret keys.
Public keys may be safe to expose in limited contexts, while secret keys must remain on a trusted server or backend function.
What counts as an API key versus a public token?
Not every credential has the same risk.
A publishable key for a payment form, for example, is designed for browser use, while a private API secret used to create charges or read protected data should never be exposed.
Before deciding how to hide API keys on a website, identify the credential type:
- Secret API key: must be stored server-side only
- Public or publishable key: can be embedded if the provider intends it
- OAuth access token: should be short-lived and scoped to a user
- Session token: should be protected with secure cookie settings and expiry
Security depends on intent and scope.
A key that looks harmless may still allow expensive or sensitive actions if it is overprivileged.
Best practice: keep secret keys on the server
The most reliable way to hide API keys on a website is to move any sensitive API call behind your own backend.
The browser talks to your server, and your server talks to the third-party API using the private key stored in a secure environment variable.
This architecture is common in Node.js, Python, PHP, Ruby, Java, .NET, and serverless platforms such as AWS Lambda, Google Cloud Functions, and Vercel Functions.
How the server-side proxy pattern works
- The browser sends a request to your application endpoint.
- Your backend authenticates the user or checks a session.
- The backend reads the secret key from server-side configuration.
- Your server calls the external API.
- Your server returns only the necessary data to the browser.
This pattern reduces exposure because the secret never crosses the client boundary.
It also gives you one central place to add validation, logging, rate limiting, and caching.
Use environment variables instead of hardcoding credentials
Never place API keys directly in source files, build scripts, or frontend constants.
Store them in environment variables and load them at runtime on the server.
Common examples include .env files in development and managed secrets in production.
Good options include AWS Secrets Manager, Google Secret Manager, Azure Key Vault, Doppler, 1Password Secrets Automation, and Kubernetes secrets with proper access controls.
Recommended practices include:
- Keep secret values out of Git repositories
- Use separate keys for development, staging, and production
- Rotate secrets regularly
- Restrict who can read environment configuration
- Audit access to secrets in cloud consoles and CI/CD pipelines
Environment variables are not magical encryption, but they are far safer than embedding credentials in deployed JavaScript.
Never rely on frontend obfuscation alone
Some developers try to “hide” API keys with minification, obfuscation, or runtime encoding.
This does not secure the key because the browser still needs to decode or use it, and attackers can inspect network traffic or runtime memory.
Techniques that do not protect a secret key include:
- Minifying JavaScript
- Base64 encoding
- Storing keys in localStorage
- Embedding values in HTML data attributes
- Reading keys from public JSON files
Obfuscation may slow down casual inspection, but it does not change the fact that the credential is client-accessible.
Treat it as a cosmetic layer, not a security control.
Restrict every key that must remain exposed
In some integrations, a browser-facing key is unavoidable.
In those cases, limit what the key can do and where it can be used.
For example, many platforms let you apply restrictions such as:
- HTTP referrer restrictions for browser-only usage
- IP allowlists for server-based calls
- API scope limits for read-only or narrow permissions
- Usage quotas to reduce abuse impact
- Separate keys per environment to isolate risk
Google Maps Platform, Stripe, Twilio, and many cloud providers support some form of restriction or scoping.
The exact controls vary, but the principle is the same: assume exposure is possible and limit damage.
How to hide API keys on a website with a backend proxy
A backend proxy is the cleanest pattern for web apps that need to call third-party services securely.
It is especially useful for search APIs, AI model APIs, geocoding, analytics endpoints, and internal business systems.
A secure proxy should:
- Accept only the parameters your frontend truly needs
- Validate and sanitize inputs before forwarding them
- Authenticate the requester
- Use server-side rate limiting
- Log abusive patterns without logging the secret itself
- Strip unnecessary fields from the provider response
This setup creates a controlled interface between your users and the external service.
It also makes it easier to swap providers later without changing every client page.
Use short-lived tokens when possible
For user-specific workflows, short-lived tokens are safer than static API keys.
OAuth 2.0 access tokens, signed session cookies, and JWTs with tight expiration windows can reduce the damage of interception or replay.
Useful patterns include:
- Generate a short-lived access token on the server
- Exchange it for a limited action or session
- Refresh only when the user remains authenticated
- Revoke or expire tokens quickly
This approach is common in identity systems, payment flows, and B2B applications where users need scoped access without seeing backend secrets.
Secure your build pipeline and deployment process
Even when your frontend does not store secrets, your build system can leak them if configuration is careless.
Static site generators, CI/CD pipelines, and preview deployments often compile environment values into assets.
Review these points carefully:
- Do not expose secret variables to frontend build steps
- Separate public environment values from private ones
- Check generated bundles and source maps for accidental leaks
- Limit secret access in GitHub Actions, GitLab CI, Jenkins, and similar tools
- Disable unnecessary logs that might print credentials
Many security incidents happen not because the app was designed poorly, but because deployment tooling copied secrets into the wrong place.
How to check whether a key has been exposed
If you suspect a leak, assume the key is compromised until proven otherwise.
Review the browser bundle, server logs, repository history, release artifacts, and third-party monitoring tools for traces of the credential.
Useful response steps include:
- Revoke the exposed key immediately
- Issue a new key with reduced permissions
- Rotate all dependent secrets if needed
- Search commit history and issue trackers for pasted values
- Check provider usage logs for abnormal traffic
Fast rotation is essential because exposed keys are often harvested automatically within minutes.
Practical checklist for safer API key handling
Use this checklist whenever you add a new integration to a website:
- Identify whether the credential is public or secret
- Keep secret keys only on trusted server infrastructure
- Store credentials in managed secrets or environment variables
- Route browser requests through a backend proxy
- Apply referrer, IP, scope, and quota restrictions where supported
- Use short-lived tokens for user-specific actions
- Audit build artifacts, logs, and source maps for leaks
- Rotate and revoke keys on a regular schedule
Following these controls will not make an application invulnerable, but it will dramatically reduce the chances that a single exposed key turns into a serious incident.