What can someone do with your leaked key?

Front-end JavaScript bundle

Anyone who opens your site can find it: view the page source, open the browser's developer tools, or search your JavaScript files. No hacking is needed.

What to do about the leak itself:

• Assume it has been copied. Removing it in a new deploy stops new copies, not old ones, so a secret key still needs rotating.
• Move the call that needs a secret into a server route, API route or Edge Function, then redeploy.

Source: Supabase: API keys; OpenAI: best practices for API key safety (read 19 October 2026).

Public Git repository

Keys in public repositories get found fast: Stripe says bad actors continuously scan public repositories for its keys. Deleting the file in a new commit leaves the key in your history.

What to do about the leak itself:

• Rotate or revoke the key first. GitHub says that once a secret is rotated it can no longer be used, which may be all you need.
• Rewriting history is optional and hard: GitHub notes copies can survive in clones, forks, cached views and pull requests.
• Add .env files to .gitignore and turn on push protection or a pre-commit secret scanner so it doesn't happen again.

Source: GitHub: removing sensitive data from a repository; Stripe: best practices for managing secret API keys (read 19 October 2026).

Environment variable exposed to the client

Prefixes like NEXT_PUBLIC_ tell your framework to copy the value into the JavaScript sent to the browser. Next.js inlines these values into the bundle at build time, so the "env var" ends up public.

What to do about the leak itself:

• Rename the variable without the public prefix and read it only in server code. Supabase's own example says: never prefix server-only keys, or your bundler will ship the key.
• Rebuild and redeploy, because public values are frozen into the build.
• Rotate the key if it's a secret: it was already public in every build that shipped it.

Source: Next.js: environment variables; Supabase: API keys (read 19 October 2026).

Supabase anon / publishable key Public by design

This key is meant to be in your front end. What it can reach depends entirely on your Row Level Security (RLS).

Step by step: what an attacker could do

1. They copy the key from your page or JavaScript. Supabase says anyone can retrieve a publishable key from code you ship, so treat it as public.
2. They call your project's API with it. Requests run as the anon Postgres role (or authenticated once they sign up to your app).
3. Any table without RLS, or with a policy that lets everyone through, can be read, and possibly written, through your API. Storage buckets and database functions follow the same grants and policies.
4. With RLS on every table and policies that check ownership, they get only what you meant to be public.

Likely damage

No billing figure applies here: the risk is your data. If RLS is off on a table, its rows can be read by anyone with the key. Supabase states that publishable keys only reach what Row Level Security allows.

How to fix it

1. Turn on RLS for every table in exposed schemas and add policies that check auth.uid() ownership.
2. Review the Security Advisor in your Supabase dashboard and fix each finding.
3. Test what a signed-out visitor can read with our free Supabase RLS checker.
4. Rotating this key doesn't help on its own: the new key is just as public. Supabase is deprecating legacy anon keys by the end of 2026, so move to sb_publishable_ keys when you can.

Source: Supabase: API keys (read 19 October 2026).

Supabase service_role / secret key Critical

This is the master key. It bypasses every Row Level Security policy you have.

Step by step: what an attacker could do

1. They copy the key from wherever it leaked.
2. They call your project's API with it. It maps to the service_role Postgres role, which has the BYPASSRLS attribute.
3. They can read, change or delete data in any table your API exposes, whatever your RLS policies say. Supabase describes secret keys as giving full access to your project's data.
4. Newer sb_secret_ keys are refused when sent from a browser, but Supabase notes an attacker can still use the key from other tools.

Likely damage

Everything in your database that the API can reach, including your users' personal data. Supabase: "Exposing a secret key puts all of your project's data at risk."

How to fix it

1. Follow Supabase's leaked-key steps: fix the cause of the leak, create a new secret key, replace the old one everywhere, confirm, then delete it (or deactivate legacy keys).
2. Move every call that needs this key to a server route or Edge Function. The browser should only ever get the publishable key.
3. Use a separate secret key for each backend component so one leak means one rotation.
4. Check your data and logs for changes you didn't make, and decide whether you must tell affected users.

Source: Supabase: API keys; Supabase: rotate a leaked or compromised key (read 19 October 2026).

OpenAI API key High

Anyone with the key can send API requests that are billed to your account.

Step by step: what an attacker could do

1. They copy the key and send requests as you, using your account's quota.
2. OpenAI warns this "may lead to unexpected charges or compromise of certain account data".
3. Heavy use can use up your monthly quota and interrupt your own app's API access.

Likely damage

Charges at OpenAI's normal per-token prices for whatever they run, billed to you, plus possible loss of data stored in your account. We don't give a figure, because it depends on how much they use the key. OpenAI recommends monthly spend limits with hard enforcement, and notes spend may slightly exceed the limit because enforcement isn't instantaneous.

How to fix it

1. Rotate the key now on the API Keys page and update your app.
2. Never call OpenAI from the browser or a mobile app. Route requests through your own backend.
3. Set project spend limits with hard enforcement, give keys an expiry date, and consider IP allowlisting.
4. Check the Usage page for activity that isn't yours, and contact OpenAI support if you see misuse.

Source: OpenAI: best practices for API key safety (read 19 October 2026).

Stripe secret key (sk_live_) Critical

A Stripe secret key is account credentials, like a username and password.

Step by step: what an attacker could do

1. They copy the key from wherever it leaked. Stripe says bad actors continuously scan public repositories for Stripe keys.
2. They make API requests as your account.
3. Stripe lists the damage: they "can make unauthorized charges, access customer data, or disrupt your integration".

Likely damage

Unauthorised charges, exposure of your customers' data, and a broken payments integration. Stripe may notify you or deactivate an exposed key, but says it doesn't guarantee detection.

How to fix it

1. Rotate the key immediately in the Stripe Dashboard, even if you aren't sure anyone saw it. Stripe treats any exposure as a potential compromise.
2. Use restricted API keys with only the permissions each part of your app needs.
3. Limit keys to your servers' IP addresses where you can, and audit your API request logs.
4. Keep secret keys only on the server, in a secrets vault or environment variables. The browser only gets the publishable key.

Source: Stripe: best practices for managing secret API keys (read 19 October 2026).

Firebase web config (apiKey) Public by design

Firebase API keys only identify your project. Your Security Rules and App Check decide what anyone can do.

Step by step: what an attacker could do

1. They copy the config object from your page. Firebase says these keys are OK to include in code.
2. They can make requests to Firebase services as your project, for example sign-up and sign-in requests to your authentication endpoints.
3. Database and storage data is protected only by your Firebase Security Rules. Open rules mean open data.
4. If the same key is also allowed to call other paid Google APIs, it can be used against your quota. Firebase specifically says never to put the Gemini Developer API on a public key's allowlist.

Likely damage

Low if the key is restricted to Firebase APIs and your Security Rules are tight. High if your rules are open, or the key can call billable non-Firebase APIs.

How to fix it

1. Write Security Rules for Firestore, Realtime Database and Storage that check the signed-in user, and turn on App Check.
2. In Google Cloud console, under APIs & Services, then Credentials, check the key's API restrictions list only Firebase APIs, and not the Generative Language API.
3. Use separate, restricted keys for any non-Firebase Google API, and keep a Gemini key server-side.
4. If you use password sign-in, consider tightening the Identity Toolkit quota to match your normal traffic.

Source: Firebase: learn about and manage API keys (read 19 October 2026).