How to Secure API Keys in Web Applications 2026 - Learn Java Online, Learn Python Online, Learn Laravel Online, Learn PHP Online

Secure API Keys in Web Applications is one of the most important security practices that every beginner developer should understand.

Modern websites and web applications frequently communicate with external services through APIs. These APIs may provide payment processing, maps, email delivery, cloud storage, analytics, artificial intelligence, authentication, or other functionality.

To authenticate requests, an API provider may issue an API key or another type of credential.

For example:

const API_KEY = "your-secret-api-key";

At first glance, this looks simple. However, putting a private API key directly into browser-side JavaScript can expose the credential to anyone who uses the application.

A better architecture is:

User Browser
     ↓
Your Backend
     ↓
API Provider

The browser communicates with your backend, while the backend securely communicates with the external API using the private credential.

This article explains how to Secure API Keys in Web Applications from the perspective of a beginner. You will learn what API keys are, why they need protection, why frontend API keys can be exposed, how environment variables work, how to use backend proxies, how to restrict API keys, how to rotate compromised credentials, and how to use secret-management tools in production.

OWASP recommends protecting API keys and other secrets through appropriate storage, access controls, lifecycle management, rotation, revocation, and detection mechanisms. (OWASP Cheat Sheet Series)

What Is an API Key?

An API key is a credential used by an application or client to identify or authorize access to an API.

A simple request might look like:

Application
     ↓
API Key
     ↓
External API
     ↓
Response

For example, an application might use a key to access:

Weather APIs
Payment APIs
Mapping APIs
Email APIs
Cloud services
AI APIs
Analytics APIs
Database services

An API key may look similar to:

API_KEY=abc123_example_secret

The exact format depends on the provider.

It is important to understand that an API key should be treated as a credential when it grants access or consumes a service. GitHub recommends treating authentication credentials like passwords or other sensitive credentials and avoiding hardcoding them in source code. (GitHub Docs)

Why You Should Secure API Keys in Web Applications

If an API key is exposed, another person may be able to use it.

Depending on the API provider and permissions, an exposed key could result in:

Unauthorized API requests
Unexpected charges
Data access
Account abuse
Quota exhaustion
Service disruption
Privacy problems
Further attacks against connected services

For example, imagine your application uses an AI API.

Your AI Application
       ↓
Private API Key
       ↓
AI Provider

If the private key is included in browser JavaScript, a user may inspect the page or application files and potentially discover the key.

The attacker can then attempt to use the credential outside your application.

This is why developers must learn how to Secure API Keys in Web Applications before deploying applications publicly.

Public API Keys vs Private API Keys

Not every key that looks like an API key has the same security requirements.

Some services intentionally provide publishable or public keys that are designed to be included in frontend applications.

Other credentials are secret keys and must remain on trusted server-side infrastructure.

For example:

Publishable Key
      ↓
May be designed for frontend use


Secret Key
      ↓
Keep on backend

Always check the API provider’s documentation to determine whether a particular key is intended to be public.

Never assume that a key is safe to expose simply because it is called an “API key.”

The correct approach to Secure API Keys in Web Applications depends on what the credential can access and how the provider expects it to be used.

Never Hardcode Private API Keys

One of the biggest mistakes beginners make is hardcoding a secret key.

Avoid:

const API_KEY = "real-secret-key";

Also avoid:

API_KEY = "real-secret-key"

And avoid:

DATABASE_PASSWORD=my-real-password

inside source-controlled configuration files.

If the repository is uploaded to GitHub, the credential may become exposed.

GitHub explicitly recommends not pushing unencrypted authentication credentials such as tokens or keys to repositories, including private repositories. (GitHub Docs)

Hardcoding also makes credential rotation more difficult because the secret may exist in multiple files and versions.

How to Secure API Keys in Web Applications With Environment Variables

Environment variables are commonly used to keep configuration separate from source code.

For local development, you might create:

.env

Then:

API_KEY=your-secret-key
DATABASE_URL=your-database-url

Your application can read the value at runtime.

Node.js

const apiKey = process.env.API_KEY;

Python

import os

api_key = os.getenv("API_KEY")

This is safer than hardcoding credentials directly into application code.

However, environment variables are not automatically secret in every environment. OWASP notes that environment variables can potentially be exposed through processes, debugging information, or other mechanisms. (OWASP Cheat Sheet Series)

For production systems, consider using a dedicated secrets-management solution when appropriate.

Create a `.env` File for Local Development

A simple Node.js project might look like:

my-web-app/
│
├── src/
├── .env
├── .gitignore
├── package.json
└── server.js

Inside .env:

API_KEY=your_real_key

Your application can access it through:

const apiKey = process.env.API_KEY;

The important rule is:

The .env file containing real credentials should not be committed to Git.

Add `.env` to `.gitignore`

Create:

.gitignore

Add:

.env
.env.*
!.env.example

This tells Git not to track your real environment files.

You can create a safe example file:

.env.example

Containing:

API_KEY=
DATABASE_URL=
JWT_SECRET=

This allows other developers to understand what configuration is required without giving them your real credentials.

This simple workflow is an important first step to Secure API Keys in Web Applications.

Why Frontend Environment Variables Are Not Automatically Secret

This is one of the most important concepts for beginners.

Suppose you build a React application.

You create:

.env

and write:

API_KEY=my-secret-key

You might think:

“The key is inside .env, so nobody can see it.”

That is not necessarily true.

If your frontend build process embeds the value into JavaScript that is delivered to the browser, users can potentially inspect the resulting application.

The browser is controlled by the user.

Therefore:

Frontend JavaScript
      ↓
User's Browser
      ↓
User can inspect it

A private API key should generally not be placed into browser-delivered code.

The Correct Architecture for Private API Keys

A safer architecture is:

                 ┌─────────────────┐
                 │  Web Browser     │
                 └────────┬────────┘
                          │
                          │ Request
                          ↓
                 ┌─────────────────┐
                 │  Your Backend   │
                 └────────┬────────┘
                          │
                          │ Private API Key
                          ↓
                 ┌─────────────────┐
                 │ External API    │
                 └─────────────────┘

The browser does not receive the private credential.

Instead, your backend makes the external API request.

This is one of the most effective architectural patterns to Secure API Keys in Web Applications.

How to Secure API Keys in Web Applications With a Backend

Suppose you have a frontend:

fetch("/api/weather")
    .then(response => response.json())
    .then(data => {
        console.log(data);
    });

Your frontend does not need to know the weather provider’s private API key.

Your backend can read:

const apiKey = process.env.WEATHER_API_KEY;

and then call the external service.

The architecture becomes:

Frontend
   ↓
/api/weather
   ↓
Backend
   ↓
WEATHER_API_KEY
   ↓
Weather Provider

The API key remains on the server.

Example: Node.js Backend API

Suppose you use Express.

A simplified backend could look like:

require("dotenv").config();

const express = require("express");

const app = express();

app.get("/api/data", async (req, res) => {

    try {

        const apiKey =
            process.env.EXTERNAL_API_KEY;

        if (!apiKey) {
            return res.status(500).json({
                error: "API key is not configured"
            });
        }

        // Call external API here

        res.json({
            message: "API request completed"
        });

    } catch (error) {

        console.error(
            "External API request failed"
        );

        res.status(500).json({
            error: "Request failed"
        });
    }
});

app.listen(3000);

The browser communicates with your backend instead of receiving the private API key.

Do Not Return the API Key to the Frontend

Even if your backend stores the key securely, you can accidentally expose it by returning it in an API response.

Never do:

res.json({
    apiKey: process.env.API_KEY
});

Instead, return only the information the frontend actually needs:

res.json({
    data: result
});

The backend should act as a security boundary.

Use HTTPS

When API requests contain authentication credentials or sensitive information, use HTTPS.

HTTPS protects data transmitted between the client and server by providing confidentiality and integrity.

OWASP recommends using properly configured TLS for web-service communication involving sensitive features, authenticated sessions, or sensitive data. (OWASP Cheat Sheet Series)

The architecture should therefore be:

HTTPS
  ↓
Browser
  ↓
HTTPS
  ↓
Backend
  ↓
HTTPS
  ↓
External API

Avoid sending sensitive credentials over unencrypted HTTP connections.

Never Put API Keys in URLs

Avoid:

https://api.example.com/data?api_key=SECRET

Query parameters can potentially appear in:

Browser history
Server logs
Proxy logs
Monitoring systems
Analytics systems
Referrer information

OWASP specifically recommends not putting sensitive information such as API keys or session tokens in URLs or query strings. (OWASP Developer Guide)

Use the authentication method recommended by the API provider, such as an appropriate request header.

For example:

fetch("https://api.example.com/data", {
    headers: {
        "Authorization": `Bearer ${apiKey}`
    }
});

The exact header format depends on the API provider.

Restrict API Key Permissions

A powerful way to Secure API Keys in Web Applications is to limit what the key can do.

Suppose an API supports these permissions:

read
write
delete
admin

If your application only needs read access, don’t give the key:

admin

Give it only:

read

This is called least privilege.

GitHub’s credential-security guidance recommends granting credentials only the minimum permissions or scopes required. (GitHub Docs)

If the credential is compromised, limited permissions reduce the potential impact.

Restrict API Keys by Application or Environment

Some API providers allow additional restrictions.

For example, you may be able to restrict a key based on:

Website origin
IP address
Application
API service
API operation
Cloud project
Environment

For example:

Production API Key
    ↓
Production Server IP
    ↓
Specific API
    ↓
Limited Operations

If your provider supports these restrictions, use them.

Restrictions do not replace proper secret management, but they provide an additional security layer.

Use Separate API Keys for Development and Production

Do not use your production API key everywhere.

Instead:

Development
    ↓
DEV_API_KEY


Staging
    ↓
STAGING_API_KEY


Production
    ↓
PRODUCTION_API_KEY

This provides isolation.

If a developer accidentally exposes the development key, the production environment is not automatically compromised.

Separating environments is a useful practice when you Secure API Keys in Web Applications.

Rotate API Keys Regularly

API keys should have a lifecycle.

A useful lifecycle is:

Create
  ↓
Use
  ↓
Monitor
  ↓
Rotate
  ↓
Revoke
  ↓
Delete

OWASP identifies creation, rotation, revocation, and expiration as important stages in the secret lifecycle. (OWASP Cheat Sheet Series)

Rotation means replacing an existing credential with a new one.

For example:

Old API Key
     ↓
Create New Key
     ↓
Deploy New Key
     ↓
Test Application
     ↓
Revoke Old Key

Plan rotation carefully so that the application does not experience unnecessary downtime.

What to Do If an API Key Is Leaked

Suppose you accidentally commit:

API_KEY=real-secret

to GitHub.

Do not simply delete the line and assume everything is fixed.

Treat the key as compromised.

Follow these steps:

Step 1: Revoke the Key

Disable the compromised credential.

Step 2: Generate a New Key

Create a replacement.

Step 3: Update Your Application

Replace the old credential with the new one.

Step 4: Check Usage

Review logs or provider dashboards for suspicious activity.

Step 5: Remove the Secret From Repository History

Depending on the situation, clean the repository history appropriately.

Step 6: Add Secret Scanning

Prevent similar incidents in the future.

GitHub recommends generating a new credential, replacing the compromised credential, and deleting the old credential when authentication credentials are exposed. (GitHub Docs)

Use GitHub Secret Scanning

GitHub provides secret scanning to detect credentials such as API keys, passwords, and tokens that appear in repositories.

GitHub says secret scanning can scan Git history for hardcoded credentials and help identify exposed secrets before they are exploited. (GitHub Docs)

GitHub also provides push protection in supported configurations to help prevent secrets from being pushed in the first place. (GitHub Docs)

This can create a workflow like:

Developer
    ↓
git commit
    ↓
Secret Scan
    ↓
Secret Found?
   ↙     ↘
 Yes      No
 ↓         ↓
Block    Commit

Secret scanning is an important additional layer when you Secure API Keys in Web Applications.

Never Log API Keys

Avoid:

console.log(process.env.API_KEY);

Also avoid:

console.log({
    headers,
    environment: process.env
});

Logs may be stored by:

Cloud platforms
Monitoring tools
CI/CD systems
Application servers
Log-management services

OWASP recommends that secrets should not be logged and should be masked or protected if they could appear in logging systems. (OWASP Cheat Sheet Series)

A safer message is:

console.log("External API configured");

rather than printing the actual credential.

Be Careful With Error Messages

Error messages can also expose API keys.

Avoid returning:

API request failed:
Authorization: Bearer abc123-secret

Instead:

External API request failed.

Detailed server-side diagnostics should also be carefully reviewed to ensure that credentials are not included.

Do Not Store Private API Keys in Local Storage

For browser applications, developers sometimes put sensitive tokens into:

localStorage.setItem(
    "apiKey",
    apiKey
);

This is generally inappropriate for private server API keys.

The better approach is to keep private API credentials on trusted server-side infrastructure.

OWASP’s secrets guidance also warns against insecure browser-side storage for sensitive bearer tokens and recommends secure, appropriate storage mechanisms. (OWASP Cheat Sheet Series)

Secure API Keys in Web Applications With a Secret Manager

For larger production systems, you may want a dedicated secret manager.

Examples include:

AWS Secrets Manager
Google Cloud Secret Manager
Azure Key Vault
HashiCorp Vault

The architecture becomes:

Web Application
      ↓
Identity / IAM
      ↓
Secret Manager
      ↓
API Key
      ↓
External API

The application retrieves only the credential it needs.

OWASP recommends centralized secret-management solutions for storing, provisioning, auditing, rotating, and managing secrets. (OWASP Cheat Sheet Series)

This approach becomes especially valuable as your application and development team grow.

How to Secure API Keys in Web Applications With CI/CD

Deployment pipelines also need credentials.

For example:

GitHub Actions
      ↓
Deploy Application
      ↓
Cloud Provider

Do not write real credentials directly inside:

API_KEY: my-secret-key

Instead, use your CI/CD platform’s encrypted secret functionality.

For example, GitHub Actions supports repository, organization, and environment secrets. (GitHub Docs)

A simplified example:

env:
  API_KEY: ${{ secrets.API_KEY }}

This keeps the credential outside your workflow source code.

Secure API Keys in Web Applications With Docker

Docker applications need special attention.

Avoid:

ENV API_KEY="my-secret-key"

Do not embed production secrets directly into Docker images.

Instead, inject secrets at runtime using the secret-management features supported by your deployment environment.

OWASP specifically discusses the risks of placing secrets in Docker ENV and ARG instructions and recommends safer runtime secret-injection approaches. (OWASP Cheat Sheet Series)

A safer architecture is:

Docker Image
     ↓
No Private API Key
     ↓
Container Starts
     ↓
Secret Injected at Runtime

Secure API Keys in Web Applications With CORS

CORS is not a replacement for API-key security.

CORS controls which browser origins are permitted to make certain cross-origin requests.

For example:

https://mywebsite.com
        ↓
Your API

You can configure the server to allow only trusted origins.

MDN recommends specifying the minimum necessary allowed origins instead of broadly allowing credentialed cross-origin requests. (MDN Web Docs)

For example:

Access-Control-Allow-Origin:
https://mywebsite.com

However, remember:

CORS does not hide an API key.

If a private API key is already included in frontend JavaScript, changing CORS settings does not make that key secret.

Secure API Keys in Web Applications With Rate Limiting

Suppose your backend exposes:

POST /api/generate

An attacker could potentially send thousands of requests.

Add rate limiting:

User
 ↓
Authentication
 ↓
Rate Limiter
 ↓
Backend
 ↓
External API

For example:

10 requests/minute/user

The exact limit should depend on your application.

OWASP recommends returning 429 Too Many Requests when API requests arrive too quickly and notes that API keys should not be the only protection for sensitive or high-value resources. (OWASP Cheat Sheet Series)

Secure API Keys in Web Applications With Authentication

Your backend should not necessarily allow anyone to call expensive external APIs.

For example:

Unauthenticated User
       ↓
      Login
       ↓
Authenticated User
       ↓
Rate Limit
       ↓
Backend
       ↓
External API

Authentication helps you associate usage with a specific account.

You can then implement:

User quotas
Subscription limits
Request limits
Usage monitoring
Abuse detection

This can significantly improve the security of applications that consume paid APIs.

API Keys Are Not Always Enough for Authentication

An API key is useful, but it should not automatically be considered a complete authentication and authorization solution.

OWASP’s REST security guidance specifically notes that API keys can help control API access but should not be relied on exclusively for protecting sensitive, critical, or high-value resources. (OWASP Cheat Sheet Series)

Depending on the application, you may need:

User authentication
Authorization
OAuth 2.0
OpenID Connect
Short-lived access tokens
Role-based access control
Rate limiting
Request validation

The correct solution depends on what your API protects.

Use HTTPS for API Requests

Never send private credentials over plain HTTP.

Use:

https://api.example.com

instead of:

http://api.example.com

TLS provides confidentiality and integrity for communication between systems.

OWASP recommends TLS for sensitive web-service communication and authenticated sessions. (OWASP Cheat Sheet Series)

Avoid API Keys in Client-Side Source Maps

Production frontend builds can generate source maps.

Depending on configuration, source maps may make application code easier to inspect.

If a secret is included in the original frontend source, hiding the source map does not make the secret safe.

The real solution is:

Do not put private API keys into browser code in the first place.

Source-map configuration can reduce unnecessary source exposure, but it cannot turn a public browser credential into a private credential.

How to Secure API Keys in Web Applications: Recommended Architecture

For a typical application using a private external API, use:

                 INTERNET
                    │
                    ▼
           ┌────────────────┐
           │    Browser     │
           └───────┬────────┘
                   │
                HTTPS
                   │
                   ▼
           ┌────────────────┐
           │    Backend     │
           └───────┬────────┘
                   │
          Authentication
                   │
             Rate Limiting
                   │
                   ▼
           ┌────────────────┐
           │ Secret Manager │
           └───────┬────────┘
                   │
                API Key
                   │
                   ▼
           ┌────────────────┐
           │ External API   │
           └────────────────┘

This architecture provides multiple security layers.

Example: Secure AI API Architecture

AI applications are a common example.

Suppose you are building an AI content generator.

Unsafe Architecture

React App
   ↓
AI API Key
   ↓
AI Provider

The key can potentially be discovered by users.

Better Architecture

React App
   ↓
POST /api/generate
   ↓
Node.js Backend
   ↓
Secret Manager
   ↓
AI API

The private credential stays on the server.

This is particularly important for applications that use paid LLM APIs.

For related learning, see:

How to Call an LLM API From JavaScript

How to Call an LLM API From Node.js

Secure API Keys in Web Applications: Project Structure

A Node.js project might look like:

secure-api-app/
│
├── src/
│   ├── server.js
│   ├── routes/
│   └── services/
│
├── .env
├── .env.example
├── .gitignore
├── package.json
└── README.md

`.env`

EXTERNAL_API_KEY=real-secret

`.env.example`

EXTERNAL_API_KEY=

`.gitignore`

.env
.env.*
!.env.example
node_modules/

Server

const apiKey =
    process.env.EXTERNAL_API_KEY;

The frontend never receives the private key.

Common API Key Security Mistakes

Beginners should avoid these mistakes.

Mistake 1: Hardcoding API Keys

const key = "secret";

Mistake 2: Uploading `.env`

git add .env

Mistake 3: Putting Secret Keys in React

const API_KEY = "...";

Mistake 4: Putting Keys in URLs

?api_key=secret

Mistake 5: Printing Keys

console.log(apiKey);

Mistake 6: Sharing Keys Through Chat

Never send credentials through ordinary chat or email.

Mistake 7: Using One Key Everywhere

Separate development, staging, and production credentials.

Mistake 8: Giving Excessive Permissions

Use least privilege.

Mistake 9: Never Rotating Keys

Credentials should have an appropriate lifecycle.

Mistake 10: Relying Only on CORS

CORS does not make a frontend secret.

Avoiding these mistakes is essential to Secure API Keys in Web Applications.

Best Practices to Secure API Keys in Web Applications

Use this checklist when building a new application:

Keep private API keys on the backend.
Use environment variables for local development.
Never hardcode private credentials.
Add .env to .gitignore.
Create .env.example with placeholders.
Use HTTPS.
Do not place secrets in URLs.
Do not expose secrets in frontend code.
Do not print credentials in logs.
Use least-privilege permissions.
Restrict API keys where the provider supports restrictions.
Separate development and production keys.
Rotate credentials periodically or when appropriate.
Revoke compromised credentials immediately.
Use secret scanning.
Use CI/CD secret storage.
Use a dedicated secret manager for production where appropriate.
Add rate limiting to expensive endpoints.
Authenticate users when appropriate.
Monitor API usage.
Have an incident-response plan.

Following these practices will make it much easier to Secure API Keys in Web Applications.

How to Secure API Keys in Web Applications During Development

A beginner-friendly workflow is:

1. Create API Key
       ↓
2. Store in .env
       ↓
3. Add .env to .gitignore
       ↓
4. Read Key From Environment
       ↓
5. Call External API From Backend
       ↓
6. Never Send Key to Browser
       ↓
7. Test
       ↓
8. Scan Repository

This is simple enough for beginners while introducing important security concepts.

How to Secure API Keys in Web Applications in Production

Production applications should use stronger controls.

A mature architecture might be:

Production Application
       ↓
Identity / IAM
       ↓
Secret Manager
       ↓
Short-Lived / Restricted Credential
       ↓
External API

Add:

HTTPS
Authentication
Authorization
Rate limiting
Monitoring
Secret scanning
Rotation
Least privilege
Incident response

OWASP recommends centralized management, auditing, rotation, revocation, and least privilege for secrets. (OWASP Cheat Sheet Series)

Frequently Asked Questions

What Does It Mean to Secure API Keys in Web Applications?

To Secure API Keys in Web Applications means protecting API credentials from unauthorized access by keeping private keys out of browser code, source repositories, logs, URLs, and other publicly accessible locations.

Can I Put an API Key in JavaScript?

Only if the provider explicitly says the credential is designed to be public. Private API keys should not be placed in browser-delivered JavaScript.

Are Environment Variables Secure?

Environment variables are useful for configuration, especially during development, but they are not automatically secure. Production applications may benefit from dedicated secret-management systems.

Should I Put API Keys in `.env`?

A .env file is commonly used for local development. Make sure it is excluded from Git and never share it publicly.

Can React Hide an API Key?

No. React runs in the user’s browser after the application is built and delivered. A private key included in frontend code can potentially be discovered.

How Should React Use a Private API Key?

Use:

React
 ↓
Backend
 ↓
Private API Key
 ↓
External API

The React application should communicate with your backend rather than directly exposing the private credential.

What Happens If an API Key Is Leaked?

Treat the credential as compromised. Revoke it, create a replacement, update your application, and investigate possible unauthorized usage. GitHub recommends replacing and deleting compromised credentials. (GitHub Docs)

Should API Keys Be Stored in GitHub Secrets?

For CI/CD workflows, GitHub Secrets can be used to securely provide credentials to workflows without hardcoding them in source code. (GitHub Docs)

Is CORS Enough to Protect an API Key?

No. CORS controls browser cross-origin access; it does not hide an API key that has already been included in frontend JavaScript. MDN explains that CORS is a browser mechanism for controlling cross-origin requests. (MDN Web Docs)

Should API Keys Be Put in URLs?

No. Sensitive API keys should generally not be included in URLs or query strings because URLs can appear in logs, history, and other systems. (OWASP Developer Guide)

How Often Should API Keys Be Rotated?

There is no single interval suitable for every application. Rotation should be based on the credential’s risk, provider capabilities, organizational policy, and whether compromise is suspected. Always rotate immediately when a secret is exposed.

Useful External Resources

When learning how to Secure API Keys in Web Applications, use trusted security documentation as your reference.

OWASP Secrets Management Cheat Sheet

This guide covers secret storage, creation, rotation, revocation, least privilege, detection, CI/CD, and secret-management practices. (OWASP Cheat Sheet Series)

OWASP REST Security Cheat Sheet

This resource explains API-key security, HTTPS, access control, rate limiting, CORS, input validation, and other REST API security practices. (OWASP Cheat Sheet Series)

GitHub API Credential Security

GitHub — Keeping Your API Credentials Secure

GitHub provides guidance on storing credentials, limiting permissions, secret rotation, and responding to exposed credentials. (GitHub Docs)

GitHub Secret Scanning

Learn how secret scanning can identify exposed API keys, passwords, tokens, and other credentials in repositories. (GitHub Docs)

MDN CORS Guide

MDN CORS Security Guide

Learn how to configure CORS appropriately for web applications and APIs. (MDN Web Docs)

Related Internal Resources

If you are learning how to Secure API Keys in Web Applications, these related tutorials can help you build a stronger AI and web-development foundation:

How to Manage Environment Secrets Safely

Learn how environment secrets, .env files, secret managers, CI/CD credentials, and production secrets should be handled.

How to Set Up Python for AI Development

Learn how to configure a Python environment for AI development.

How to Call an LLM API From JavaScript

Learn how to call an LLM API from JavaScript while keeping private credentials on the backend.

How to Call an LLM API From Node.js

Learn how Node.js can be used as a secure server-side layer for API integrations.

How to Build a Simple AI Chatbot With JavaScript

Learn how to create a JavaScript chatbot and understand the frontend/backend architecture required for AI applications.

Conclusion

Learning how to Secure API Keys in Web Applications is an essential skill for beginners and experienced developers alike.

API keys are credentials. If a private key is exposed, someone else may be able to use the associated service or account. Therefore, protecting API keys should be considered part of the application’s architecture rather than an afterthought.

The most important rule is:

Never expose private API keys in browser-side code.

Instead, use:

Browser
   ↓
Your Backend
   ↓
Secret Manager / Environment
   ↓
External API

For local development, environment variables and .env files can provide a convenient way to keep credentials outside source code. For production applications, dedicated secret-management systems, CI/CD secret stores, least-privilege permissions, credential restrictions, rotation, monitoring, and secret scanning can provide stronger protection.

Remember these core principles:

Never hardcode private API keys.
Never commit real credentials to Git.
Do not expose private keys through frontend JavaScript.
Do not put sensitive API keys in URLs.
Use HTTPS.
Use least-privilege permissions.
Separate development and production credentials.
Never log secrets.
Rotate and revoke compromised credentials.
Use secret scanning and production secret managers when appropriate.

Once you understand these practices, you can confidently build web applications that communicate with external APIs without unnecessarily exposing sensitive credentials.

Whether you are building an AI chatbot, payment application, weather application, SaaS platform, or another API-driven website, knowing how to Secure API Keys in Web Applications will help you build applications that are safer, more maintainable, and better prepared for production.

What Is an API Key?

Why You Should Secure API Keys in Web Applications

Public API Keys vs Private API Keys

Never Hardcode Private API Keys

How to Secure API Keys in Web Applications With Environment Variables

Node.js

Python

Create a .env File for Local Development

Add .env to .gitignore

Why Frontend Environment Variables Are Not Automatically Secret

The Correct Architecture for Private API Keys

How to Secure API Keys in Web Applications With a Backend

Example: Node.js Backend API

Do Not Return the API Key to the Frontend

Use HTTPS

Never Put API Keys in URLs

Restrict API Key Permissions

Restrict API Keys by Application or Environment

Use Separate API Keys for Development and Production

Rotate API Keys Regularly

What to Do If an API Key Is Leaked

Step 1: Revoke the Key

Step 2: Generate a New Key

Step 3: Update Your Application

Step 4: Check Usage

Step 5: Remove the Secret From Repository History

Step 6: Add Secret Scanning

Use GitHub Secret Scanning

Never Log API Keys

Be Careful With Error Messages

Do Not Store Private API Keys in Local Storage

Secure API Keys in Web Applications With a Secret Manager

How to Secure API Keys in Web Applications With CI/CD

Secure API Keys in Web Applications With Docker

Secure API Keys in Web Applications With CORS

Secure API Keys in Web Applications With Rate Limiting

Secure API Keys in Web Applications With Authentication

API Keys Are Not Always Enough for Authentication

Use HTTPS for API Requests

Avoid API Keys in Client-Side Source Maps

How to Secure API Keys in Web Applications: Recommended Architecture

Example: Secure AI API Architecture

Unsafe Architecture

Better Architecture

Secure API Keys in Web Applications: Project Structure

.env

.env.example

.gitignore

Server

Common API Key Security Mistakes

Mistake 1: Hardcoding API Keys

Mistake 2: Uploading .env

Mistake 3: Putting Secret Keys in React

Mistake 4: Putting Keys in URLs

Mistake 5: Printing Keys

Mistake 6: Sharing Keys Through Chat

Mistake 7: Using One Key Everywhere

Mistake 8: Giving Excessive Permissions

Mistake 9: Never Rotating Keys

Mistake 10: Relying Only on CORS

Best Practices to Secure API Keys in Web Applications

How to Secure API Keys in Web Applications During Development

How to Secure API Keys in Web Applications in Production

Frequently Asked Questions

What Does It Mean to Secure API Keys in Web Applications?

Can I Put an API Key in JavaScript?

Are Environment Variables Secure?

Should I Put API Keys in .env?

Can React Hide an API Key?

How Should React Use a Private API Key?

What Happens If an API Key Is Leaked?

Should API Keys Be Stored in GitHub Secrets?

Is CORS Enough to Protect an API Key?

Should API Keys Be Put in URLs?

How Often Should API Keys Be Rotated?

Useful External Resources

OWASP Secrets Management Cheat Sheet

OWASP REST Security Cheat Sheet

GitHub API Credential Security

GitHub Secret Scanning

Create a `.env` File for Local Development

Add `.env` to `.gitignore`

`.env`

`.env.example`

`.gitignore`

Mistake 2: Uploading `.env`

Should I Put API Keys in `.env`?