Check a public GitHub repo for leaked API keys

What the free check covers

The repository check is read-only and does not execute any project code. You get 3 free checks a day on the default branch of public repositories.

The default Focused check reviews current application and configuration files across folders and looks for exposed API keys, access tokens, passwords and personal data. Dependencies in several lockfile formats are compared against the public OSV database, so you also see known vulnerable packages.

Some areas are deliberately left out of the focused check: dependency folders, caches, common media, binary and archive formats, and Git history. Each exclusion is listed in the coverage report, so you always know what was not inspected. The check runs within a fixed budget (10 minutes and 2 GiB of inspected content), and anything that hit a limit is reported individually.

Step by step

1. Open redaxa.getcertsprint.com/github.html.
2. Paste the repository link, for example https://github.com/owner/repo.
3. Leave Focused check selected. The Include history & archives option (past commits, dependencies, supported archives) is part of Pro and Business.
4. Select Check repository →.
5. Read the results. The most urgent findings come first, with values hidden until you choose to reveal them. You can copy or download the report with secrets still hidden, which makes it safe to share with a teammate or client.

What to do with a finding

Treat any real credential in a public repository as exposed, even if the commit was pushed minutes ago. GitHub's own guidance is clear on the first step: "you need to revoke and/or rotate that secret." Deleting the line in a new commit does not help, because the value stays in the history, and GitHub notes that after a rewrite the commits "may still be accessible elsewhere," including "in any clones or forks of your repository." Rotate first, clean up second. Source: Removing sensitive data from a repository (GitHub Docs).

A practical order of operations:

1. Revoke or rotate the key with the provider that issued it.
2. Move the new value to an environment variable or a secret manager, and make sure the file that held it is ignored by Git.
3. Rewrite history only if you understand the consequences for forks and clones. GitHub's guide covers the available tools.
4. Run the check again to confirm the current branch is clean.

One honest limit: Redaxa does not test any key against its provider, so a finding may be an expired key, a sample value or a placeholder. You make that call, and the report gives you the location to make it quickly.

When the focused check is not enough

A focused check answers the question "is there something exposed in the current files right now?" It does not answer "was there ever a key in this repository?" For that you need Git history, other branches and tags, commit messages and archives.

With Pro or Business, those run on your own PC in the Windows app (Redaxa 0.4.0 or later), along with private repositories and revealed values. The web check also moves from 3 to 60 checks a day. Pro is €79.90 a year (€6.66 a month, billed yearly); see plans and pricing. Repository checks are an exposure review, not a complete code vulnerability audit, and the Windows app is clear about that in its own coverage report.

If you share code snippets or logs with an AI assistant as part of fixing the leak, run them through a prompt check first. The same key you are rotating has a habit of showing up in stack traces, and our checklist of what not to paste into ChatGPT covers the rest.

Related guides

• Before you paste: protecting client and project names in AI prompts
• What not to paste into ChatGPT: a checklist for freelancers and agencies
• Keep the question. Remove the secrets.