How to Find Exposed API Keys in a GitHub Repo (Free, No CLI)

You shipped fast, and somewhere in that rush an API key ended up in your GitHub repo. It happens to everyone — a config file committed by accident, a key hard-coded "just to test it," a .env that never made it into .gitignore. The good news: finding exposed keys is not hard, and you don't need to be a security engineer or touch a terminal to do it. This guide walks through the manual methods, where they fall short, and the fastest way to check the whole repo — code and git history — at once.

What an exposed API key actually looks like

Most keys follow a recognizable pattern. If you spot any of these in your files, you've found a secret that needs handling:

• AKIA… — an AWS access key ID (usually paired with a longer secret access key nearby).
• sk_live_… — a Stripe live secret key. The one that moves real money.
• sk-… (OpenAI) and sk-ant-… (Anthropic) — LLM API keys that bill straight to your account.
• ghp_… — a GitHub personal access token, which can read or push to your repos.
• A Supabase service-role key — a long JWT that bypasses row-level security and can read or write your entire database.

That's a handful of the roughly 22 secret types worth hunting for. See the full list and examples on the detection reference, or jump straight to the pages for the AWS access key and the GitHub token.

Method 1: GitHub's built-in secret scanning

GitHub runs free secret scanning on public repos, and push protection that tries to block a commit before a known secret ever lands. When it works, it's great: you get an alert (or a blocked push) the moment a recognized pattern shows up.

What it catches

• Well-known token formats from partner providers (AWS, Stripe, GitHub, and many more) that GitHub has fingerprints for.
• New secrets at push time, if push protection is enabled — it stops the leak before it's public.

What it misses

• Private repos historically needed a paid plan for full alerting. If yours is private, don't assume you're covered.
• Keys that don't match a known partner pattern — a homegrown API key, an internal token, or a generic PASSWORD= in a config slips right through.
• Secrets committed before you turned protection on. Scanning your history is a separate step, and it's the one people skip.

Method 2: Search the code and git history by hand

GitHub's in-page search only looks at the current state of your files. A key you committed and later "removed" is still sitting in your history, fully readable to anyone who clones the repo. To find those, you have to look deeper.

Search current files

On github.com, use the repo search box for tell-tale prefixes like AKIA, sk_live_, sk-ant-, or ghp_, and for filenames like .env. This is quick but shallow — it only sees what's in the latest commit.

Search the full history

If you're comfortable with a terminal, git log -p prints every change across every commit, so you can scroll (or grep) for a leaked value that was later deleted. This is the honest test: if a key was ever committed, it shows up here.

The catch nobody warns you about: removing a secret from your newest commit does not remove it from history. The old commit still contains it. Truly scrubbing it means rewriting history (with something like git filter-repo) and force-pushing — which is fiddly, easy to get wrong, and pointless if the repo was already public.

Method 3: Scan the whole repo at once (no CLI)

Manual methods work, but they're slow and you have to know exactly what to look for. A scanner does the tedious part for you: it clones the repo, reads every file, walks the full git history, and matches against roughly 22 secret patterns — the AWS, Stripe, OpenAI, Anthropic, Supabase, and GitHub formats above, plus many more. No terminal, no setup.

With Trust you paste a GitHub URL and get a plain-language report: which secret, which file, which line, and what to do next. It also flags unsafe code patterns (SAST) and vulnerable dependencies in the same pass — the stuff that quietly ships alongside a leaked key, especially in AI-generated projects (more on that in is your AI-generated app secure?). And if you live in Cursor or Claude Code, you can run it without leaving your editor through the MCP integration.

You found a key. Now what?

This is the part that matters most, and it's where people get the order wrong. Rotation beats deletion — every time. Once a key has been public, even for a minute, you must assume a stranger has a copy. Automated bots scrape new public commits within seconds of them appearing, so deleting the file is like locking a door after someone already copied the key.

1. Rotate (revoke) the key in the provider's dashboard — Stripe, AWS, OpenAI, GitHub, Supabase. This makes the leaked value useless. Do this first.
2. Remove it from your code and load it from an environment variable or a secrets manager instead. Add the file to .gitignore.
3. Clean the history if it's worth it (private repo, sensitive key) — but only after rotating, because scrubbing history does nothing about the copies bots already took.
4. Turn on push protection so the next accidental commit gets blocked before it leaks.

The takeaway

GitHub's built-in scanning is a solid start, and a two-minute manual search catches the obvious stuff. But the leaks that hurt are the ones hiding in old commits and in non-standard key formats. A full repo scan covers all of it in one shot — code, history, and ~22 secret types — without a single terminal command. Run it now, rotate anything it finds, and get back to shipping.