How the Attack Works

A secret (API key, bearer token, database connection string) authenticates a caller to an API. Whoever knows the secret is treated as a legitimate caller - it must therefore be handled like a password.

It typically leaks through four channels:

  • Hardcoding in shipped code: especially in mobile apps or JavaScript frontends, where the secret can be extracted by decompiling or reading it directly in the browser.
  • Checking into version control: especially into public repositories, where it remains discoverable via the Git history even after deletion.
  • Logs: according to OWASP REST Security, credentials in the URL are captured in web server logs, and the Logging Cheat Sheet explicitly counts access tokens, passwords, connection strings, and encryption keys among the data that must never be logged directly.
  • URL/query parameters: secrets in the URL end up in server logs, proxy logs, browser history, and referer headers.

Because a secret identifies the caller like a password, whoever finds it can address the API with the rights of the legitimate owner until the secret is rotated or revoked.

1. Starting PointKey or token in client code, repo, log, or URL
→
2. AttackAttacker finds the secret
→
3. ResultFull API access with someone else's key

Exposed keys give attackers direct API access.

Example

API Key in URL vs. Header (OWASP)
NOT OK:
GET https://example.com/controller/123/action?apiKey=a53f435643de32

OK (secret in header):
GET https://example.com/resourceCollection/123/action
Authorization: Bearer a53f435643de32

Impact

An exposed secret immediately grants attackers the legitimate owner's access rights to the API. This includes data access, data manipulation, or paid use of billable services at the victim's expense.

According to OWASP, credentials stored in URLs or logs are "intrinsically valuable" precisely because they get captured in web server logs and persist there.

As long as the secret is not rotated or revoked, unauthorized access continues. Regular rotation limits this window - according to OWASP, for example, stolen database credentials would already have expired by the next restart if short rotation intervals are set.

How to Protect Yourself

  • Never transmit secrets in URLs or query parameters - for GET, place them in an HTTP header; for POST/PUT, place them in the body or a header (OWASP REST Security).
  • Don't log access tokens, passwords, database connection strings, and encryption keys in plaintext; remove, mask, sanitize, hash, or encrypt them before logging (OWASP Logging Cheat Sheet).
  • Don't hardcode secrets in client/mobile code or in version control; instead centralize and standardize secrets management (OWASP Secrets Management).
  • Restrict access to secrets via access control/IAM following least privilege, and enforce secrets management through policies.
  • Rotate secrets regularly (ideally automated) so stolen credentials are only valid for a short time, and revoke immediately and securely if compromise is suspected.
  • Give secrets an expiration date wherever possible, so they become invalid automatically.
  • Use secret detection to find checked-in or exposed secrets, and run the documented incident response process (rotation/revocation) whenever one is found.
  • Enforce TLS everywhere, so secrets cannot be intercepted in transit.

Sources

Keep reading
OverviewOWASP API Security Top 10 AttackJWT Attacks