Protect API Keys Before Deploying an AI-Built Website or Web App

Check your AI-built project for exposed API keys, move sensitive calls to the server, and keep secrets private before going live.

Roadmap & Resources

Check for Exposed Secrets

Let AI Inspect the Project

Before changing anything, let AI inspect where the project uses API keys and whether any private secret can reach the browser.

One rule is enough here: a private API key should not be shipped to the browser. The prompt works out the technical details for you.

Check for Exposed API Keys

Inspect the project for private API keys or secrets that could be exposed in the browser without changing anything yet.

Inspect this project for API keys, tokens, credentials, or other private secrets that could be exposed after deployment. Do not change any files yet. Check: - Client-side source code - Environment-variable usage - API requests made directly from the browser - Configuration files - Build-time variables that may be bundled into client code - Hardcoded keys or tokens - Any AI API or third-party service that requires a private credential Separate values into: 1. Public values that are safe to expose 2. Private secrets that must stay server-side For every private secret, tell me: - Where it is currently used - Whether it can reach the browser - Why that is unsafe - What needs to change Do not give me a generic security checklist. Inspect this actual project and report only relevant findings. Do not fix anything yet.

Some of what it lists will be public values that are meant to be visible. Only the private ones matter from here.

Move Sensitive Calls to the Server

Let AI Fix the Exposed Calls

Now let it make the change, using what it just found.

Protect the Private API Calls

Move any sensitive API calls out of the browser and keep the current app behavior working.

Using the findings from the previous step, fix the project so private API keys and secrets are never exposed to the browser. For every affected feature: - Move the sensitive API call to the server-side part of the application - Keep the private secret available only on the server - Let the frontend send only the information required for the request - Return only the result the frontend needs - Keep the current user experience and functionality unchanged Requirements: - Do not expose private secrets in client-side code - Do not hardcode credentials - Do not redesign the app - Do not add unrelated features - Do not refactor unrelated code - Keep the implementation appropriate for the project's existing framework After making the changes, summarize: - What was exposed before - What now runs server-side - Which private environment variables the project now requires

Keep the list of private environment variables it gives you. The next step uses it.

Add the Production Secrets

List What Production Needs

The private value now lives on the server side, so the live version needs its own copy of it.

Prepare the Production Secrets

List the private environment variables the deployed app needs and confirm that none belongs in browser code.

Review the corrected project and prepare the secret configuration needed for production. List only the private environment variables or secrets that must be configured on the hosting platform. For each one, tell me: - Variable name - What service it belongs to - Whether it is required in production - Whether it must remain server-side Do not print or reveal actual secret values. Also confirm that no private key is still required by client-side code. Do not make unrelated project changes.

Add the Variables Where Your Host Keeps Secrets

This part is done in your hosting platform, not in the project.

Most hosting platforms provide environment-variable or secret settings for the deployed app. Add each private variable from the list there using its real value. For production, keep the real secret in your hosting platform's secret settings — not in committed project files or client-side code.

Test the Live App Safely

Deploy the Corrected Project

Publish or update the project the same way you normally do — nothing about your deployment workflow changes here.

Check the Live App Yourself

A quick pass through the live version before you ask the AI anything.

The website or web app loads

The AI or API-powered feature still works

Refreshing the page still works

No secret value appears visibly in the interface

Have AI Confirm the Key Is Protected

The last check is the one you cannot do by looking at the page.

Verify the Secret Is Protected

Check the deployed app and confirm that the private API key is no longer exposed while the feature still works.

Perform a focused security check of the deployed version after the fix. Verify: - The affected feature still works in production - Private API calls are handled server-side - No private API key or secret is included in client-side source or browser-delivered code - No secret value appears in public configuration - Required production environment variables are available - The fix did not break the existing user flow If a private secret is still exposed, identify exactly where it is leaking and fix only that issue. Do not redesign the app. Do not add new features. Do not perform unrelated cleanup. When finished, report whether the private secrets are protected and whether the feature works correctly.

Open the live app and test the affected feature yourself one last time.