streaak/keyhacks: a curl reference for checking leaked API keys

What streaak/keyhacks actually is

The repository contains a single top-level file, README.md. There is no package manifest, no source directory, no test suite and no release. The README opens by describing the project as a set of methods to validate API keys found during a bug bounty program or a pentest, and its body is a long table of contents followed by per-service sections. Each section names a service, links to that service's own API documentation, and gives one or more shell commands, usually curl, that a reader can paste into a terminal after substituting the leaked key.

The intended user is someone who already holds a candidate key. Keyhacks does not find keys, crawl JavaScript bundles, or watch GitHub commits. It answers a narrower question: I have this string, does the provider still accept it, and what does the provider return when it does? That framing matters because it sets the scope of everything else in the repository. There is no scoring, no severity, no deduplication and no output format. The deliverable is a snippet you run yourself and read yourself.

How a Keyhacks entry is structured

Every entry follows the same shape: a heading that names the credential type, a link to the vendor's documentation, and a fenced command block. The command encodes the validation logic, and the surrounding prose, when present, tells you how to read the response. The Slack Webhook entry is the clearest example of that pattern, because it states that a response of missing_text_or_fallback_or_attachments means the URL is valid and that any other response means it is invalid. The check works by sending a deliberately empty payload: a live webhook rejects it in a recognisable way, a dead one does not.

Most entries are less explicit. The Slack API token entry offers two forms of the same check, one passing the token as a query parameter to slack.com/api/auth.test and one passing it as a Bearer token in an Authorization header. The GitHub entry goes further and includes a command that greps the X-OAuth-Scopes header out of a rate_limit response, which tells you not just whether the token works but what it can reach. That is the ceiling of the repository's ambition. Nothing here chains requests together, and nothing parses a response into a verdict for you.

Running your first check

There is nothing to install. The README gives no installation section, no package name and no build step, because the project is documentation. You need curl and the credential you want to test. Open the README, find the service, copy the block, and replace the placeholder with your key.

The Slack Webhook entry is the safest first run because the README spells out both outcomes. The command posts an empty JSON body to the webhook URL:

curl -s -X POST -H "Content-type: application/json" -d '{"text":""}' "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"

If the response contains missing_text_or_fallback_or_attachments, the README says the URL is valid. Any other response means it is not. Note the side effect: you are posting to a live integration, so a valid webhook will register activity in the target workspace.

For a Slack API token the README gives a header-based variant, which keeps the token out of the URL:

curl -sX POST "https://slack.com/api/auth.test" -H "Accept: application/json; charset=utf-8" -H "Authorization: Bearer xoxb-TOKEN_HERE"

Some entries need more than one step. The Firebase section states that it requires a custom token and an API key, then gives two commands: the first exchanges the custom token for an ID token and refresh token, and the second exchanges that ID token for an auth token. Read those in order, because the second depends on output from the first.

Where Keyhacks stops being the right tool

The repository is a manual reference and behaves like one. If you have fifty candidate keys across a dozen services, Keyhacks gives you fifty copy-and-paste operations and no way to record which ones succeeded. There is no batch mode, no exit codes documented for scripting, and no machine-readable output.

Coverage is also uneven, which is a maintenance problem rather than a design one. Entries are only as current as the last edit, and the last push to the default branch was on 2026-08-07. The README does not document a deprecation policy, a review cadence or a way to mark an entry as broken, so a snippet that no longer matches the vendor's API looks identical to one that does. Vendor rate limits and abuse detection are not discussed either, which matters when you point a loop at a provider.

There is a legal and ethical boundary the README does not draw. Validating a credential you found in an authorised bug bounty or pentest scope is one thing; the same command against a key you have no permission to touch is another. Keyhacks assumes you already know which side you are on, and it offers no guidance if you do not.

Keyhacks against a scanner like Gmapsapiscanner

The closest thing to an alternative in the search data is Gmapsapiscanner, and the difference is the direction of travel. A scanner starts from a target and tries to discover exposed keys, then reports what it found. Keyhacks starts from a key you already have and asks whether it is live. They meet in the middle but they are not substitutes.

If your problem is I do not know whether this Google Maps key is restricted, you want the check, not the discovery. If your problem is I do not know which keys this application leaks, a discovery tool is the entry point and Keyhacks is the second step. The repository itself points in that direction: the README notes that @Gwen001 scripted the entire process as keyhacks.sh in the gwen001/pentest-tools repository, which is a separate project with its own code. That script is the automation layer Keyhacks deliberately does not contain.

Maintenance, licensing and what to verify

The repository is not archived, and the last push was on 2026-08-07, so it is not abandoned. It is also not a software project with a versioned release you can pin. There are no releases, no changelog and no tags in the repository, which means an upgrade is simply whatever changed in README.md since you last read it. If you copy snippets into your own notes, you have forked them, and nothing will tell you when a vendor changes an endpoint.

The licence is not stated anywhere in the repository. The top level holds README.md and no licence file, so there is no licence identifier to check. Treat that as unresolved rather than permissive: if you intend to redistribute the snippets or embed them in a commercial tool, confirm the terms with the maintainer first. Nothing in this article is legal advice.

Before trusting an entry, confirm the vendor link still resolves, run the command against a credential you control first, and record which entry you used and when. The README does not do any of that bookkeeping for you.

Editorial conclusion

Keyhacks suits a pentester or bug bounty hunter who has already found a key and wants the shortest documented request that proves it works, and who is comfortable running that request by hand and interpreting the response. It does not suit anyone who wants automated discovery, batch validation or a report, because the repository ships no code beyond the README and no releases. Before relying on an entry, verify three things: that the service is still in the table, that the endpoint in the snippet still responds the way the surrounding note says it should, and that the licence situation is acceptable, since the repository does not state one. Start with the Slack Webhook entry if you want to see the pattern, because its documented success and failure strings make the result unambiguous.

Frequently asked questions

Official sources

1. Issues
2. README
3. streaak/keyhacks on GitHub