Your API Key Is in Your Homepage Code. The 10-Minute Fix for Vibe-Coded Sites

“Can someone steal the key from my homepage?”

A founder asked me this after launching a site built with an AI-assisted builder. The answer was simple: if the key is inside your HTML, JavaScript, public config file, or browser-loaded API route, assume it is already public.

You do not need to be technical to fix this. Follow the steps below before you launch, or fix the issue now if your site is already live.

Why a frontend API key is public

Your browser must download frontend code to run your website. That means visitors can inspect:

HTML source
JavaScript bundles
Script tags
Public configuration files
Source maps
Network requests
Browser storage
Static JSON files

Search crawlers can access much of the same material. Googlebot can fetch your public HTML and JavaScript. Search systems connected to ChatGPT and other answer engines may also read public pages and assets. Crawlers such as GPTBot, OAI-SearchBot, and PerplexityBot are not a security boundary.

If a secret is in code delivered to the browser, it is not secret.

A fast website builder can create this problem without warning. You paste a key into a prompt, a tool generates a working script, and the site launches. The feature works, but the credential may be sitting in:

<script>
  const apiKey = "your-secret-key";
</script>

It may also appear in:

config.js
.env files accidentally copied into a public folder
app-config.json
A client-side API request
A debug page
A source map
An API route that was generated as frontend code instead of server-side code

Google’s API key security guidance says not to include keys in client code or commit them to repositories. The same principle applies to every public website.

The real SEO and AEO risk

This is not only a security problem.

A public secret can create:

Unexpected API charges
Unauthorized requests
Account suspension
Data exposure
Spam sent through your services
Downtime while you recover the account
A damaged reputation with customers

It can also create a search visibility problem.

Your homepage code is part of your public technical footprint. Googlebot and other crawlers may retrieve the page source, scripts, metadata, and linked public files. If a crawler encounters broken scripts, an exposed debug endpoint, or a site that has been abused through a leaked credential, your technical quality can suffer.

That affects the broader work of AI search optimization, traditional SEO, and answer engine optimization.

A site that loads reliably, exposes clear public content, and keeps private systems behind the server is easier to crawl and safer to cite. A site with broken API calls, suspicious redirects, or compromised content creates weaker signals for search engines and answer engines.

Do not try to solve this by blocking every crawler. A robots.txt file cannot protect a secret that is already in your JavaScript. Anyone can view the file directly.

Which keys are safe to expose?

Some keys are designed for browser use. Others must never reach the browser.

Credential type	Safe in browser code?	Examples	What to do
Publishable key	Usually, if restricted	Stripe publishable key	Limit its permissions and allowed domains
Site key	Usually	reCAPTCHA site key	Use only with the matching secret server-side
Analytics ID	Usually	Public measurement or tracking ID	Treat it as public and avoid putting private data into events
Secret API key	No	OpenAI, payment, email, storage, or vendor secret key	Rotate it and move it server-side
Service role key	No	Database administrator or backend service key	Revoke it immediately and replace it
Database connection string	No	PostgreSQL, MySQL, Redis, or hosted database URL	Remove it from public files and rotate credentials
SMTP password	No	Email provider password or mail token	Change it and check for unauthorized sending
Private access token	No	OAuth refresh token, admin token, deployment token	Revoke it and inspect account activity

A publishable key is only safe when the provider designed it for public use and you apply the provider’s restrictions. A key named PUBLIC_, NEXT_PUBLIC_, or VITE_ is not automatically safe. Those prefixes often mean the value will be bundled into browser code.

❌ vs ✅: The fast comparison

❌ Unsafe approach	✅ Safer approach
Put a secret in a script tag	Keep the secret in a server-side environment variable
Call a vendor API directly from the browser	Call your own server-side function
Commit `.env` to a public repository	Add `.env` to `.gitignore` and use your host’s secret settings
Hide a secret with minification	Remove the secret from browser-delivered code
Block Googlebot and AI crawlers	Keep public content crawlable and protect private credentials properly
Reuse one unrestricted key everywhere	Create separate, restricted keys for development and production

The 10-minute fix for a leaked key

1. Rotate the key first

Do not start by editing the code. Assume the old credential is compromised.

Open the provider’s dashboard and:

Create a replacement key.
Revoke or delete the exposed key.
Review usage, billing, logs, and recent requests.
Set an alert for unusual activity.

If the key belongs to a database, email account, payment service, or deployment platform, change the related password or token too.

Rotation matters because deleting the visible string from your homepage does not undo copies in browser caches, repositories, build logs, screenshots, or crawler archives.

2. Find every copy

Search your project and hosting settings for:

API_KEY
SECRET
TOKEN
PASSWORD
DATABASE_URL
SMTP
Provider-specific key prefixes
The first and last few characters of the exposed key

Check:

Homepage source
JavaScript bundles
Public folders
Static JSON files
Git history
Build logs
Source maps
Environment variable settings

Do not paste a real secret into a chat, issue tracker, or support forum while asking for help.

3. Move the credential server-side

Create a server-side function, backend route, edge function, or server action that makes the privileged request.

The browser should call:

your-site.com/api/send-request

Your server should then add the private credential and contact the third-party service.

Store the replacement key in your hosting provider’s environment variables. Do not use a public variable prefix for a secret. For example, a variable intended for browser code may be exposed during the build process.

If your builder has a “server secret,” “backend variable,” or “private environment variable” setting, use that option. If it does not, use the provider’s serverless function feature or ask the builder to generate a server-side route specifically.

4. Restrict the replacement

Apply the smallest permissions possible.

Restrict the key by:

Website origin or server IP, where supported
API product
Read or write permission
Development versus production environment
Daily request volume
Spending limit
Expiration date

Create separate credentials for testing and production. Do not give a small contact form access to your entire database.

5. Re-scan the live site

Open your homepage in a private browser window. Then:

View the page source.
Search loaded JavaScript for the old key.
Search for the replacement key.
Check public configuration files.
Inspect browser network requests.
Check whether source maps reveal the original secret.

The replacement secret should never appear in the browser. The browser should only see a safe public key or a request to your server-side function.

6. Add a robots.txt rule as defense in depth

After removing the secret, use Smart Analytics’ free Robots.txt Generator to block accidental private paths such as:

User-agent: *
Disallow: /config/
Disallow: /api/debug/
Disallow: /private/

Only add paths that should never be crawled. Do not block your main JavaScript bundles, homepage, product pages, or useful documentation if you want strong SEO and AEO visibility.

Remember, robots.txt is an instruction for cooperative crawlers. It is not authentication and cannot protect an exposed password.

Before-you-launch checklist

Complete this list before sending traffic to your new site:

Search the frontend code for secrets and tokens.
Check public configuration files and source maps.
Rotate every credential that was exposed.
Move private keys to server-side environment variables.
Route privileged requests through a server-side function.
Restrict production keys by permission, origin, usage, and budget.
Add .env and local secret files to .gitignore.
Remove debug routes and test credentials.
Re-scan the live site after deployment.
Keep public pages crawlable for Google and answer engines.
Generate a clean robots.txt file.
Check your SEO, AEO, and security status before launch.

Frequently asked questions

Can someone steal an API key from my homepage?

Yes. If the key is included in HTML, JavaScript, a public configuration file, or a browser request, visitors and automated crawlers can read it. Treat it as compromised, rotate it, and move the replacement to a server-side function.

Is a publishable key safe to expose?

Usually, if the provider designed it for public use. Publishable and site keys must still have strict restrictions. Never expose secret keys, service role keys, database strings, SMTP passwords, private tokens, or administrator credentials.

Will robots.txt hide my secret from Googlebot?

No. Robots.txt can discourage crawling of selected paths, but it does not remove a credential from a public file and does not stop direct access. Remove the secret, rotate it, and protect the replacement server-side.

Check your site before you launch

Use the completely free Smart Analytics Vulnerability Check to check for exposed files, leaked passwords or API keys, missing protections, unsafe forms, cookie issues, and other website vulnerabilities.

You get a security score and a downloadable PDF report. Specific vulnerability findings stay private in that PDF instead of being exposed publicly. The tool also creates a custom fix prompt for non-developers who need practical guidance.

There is no login, no email requirement, no paywall, and no locked premium report. You get the full result every time.

Then run the free SEO and AEO analyzer to review technical SEO, metadata, schema, internal links, crawlability, and answer engine optimization.

Use the free tools to fix the remaining launch issues:

Fast building is useful. Fast building with a secret in your homepage is expensive. Rotate the key, move it server-side, restrict it, re-scan the site, and launch with confidence.