Check your code for leaked API keys and secrets

This prompt finds places where secrets could leak: hard-coded keys, tokens in frontend code, keys in logs and committed .env files. It ends with the steps to take, in order, if a key has already been pushed.

text-code-secrets-leak-check — claude — 89 words

Act as a security engineer.

Code or config files:
[PASTE, with any real keys replaced by XXXX]
Where the code lives: [e.g. public GitHub repo, frontend bundle, mobile app]

Find every place where a secret could leak: hard-coded keys, tokens in frontend code, keys in logs or error messages, .env files that could be committed, and secrets in URLs. For each, explain the risk and the fix. Then give me a checklist for what to do if a key has already been pushed to Git, in the right order.

Edit in the builder Copy & open Claude ↗Copy & open ChatGPT ↗Copy & open Gemini ↗

If a real key was ever pushed, rotate it first. Deleting it from Git history is not enough, because it may already be copied.

Get a better result

What you will get

A list of every place a secret could leak in your code, from hard coded keys and tokens in frontend bundles to logs, committed .env files and URLs, each with the risk and the fix, plus an ordered checklist for a key already pushed to Git.

Why it works

Saying where the code lives changes the risk: a key in a private server file is very different from one in a public repo or a frontend bundle. The list of leak points covers the less obvious places, like logs and URLs. The ordered checklist matters because the right order, rotate first, is the opposite of what most people do in a panic.

Common mistake

You paste the real keys into the chat.

Fix: Replace them with XXXX first, as the prompt says. The check only needs to know where a key sits, not what it is.

Also watch for

It suggests hiding a key in frontend code. Anything shipped to a browser or app can be read. Ask for a small server route that calls the API so the key never leaves your server.
The checklist starts with cleaning Git history. Rotate the key first, as the tip says. Cleaning history comes after, because copies may already exist.

Try a variation: review a mobile app

Say the code is a mobile app and ask which keys are safe to ship, like restricted public keys, and which must move to a server.

Still not right? Reply with this

Write a pre-commit check that blocks files containing key-like strings, and tell me how to install it in this repo.