API Keys, Tokens, and Secrets: How They Leak and How Developers Can Avoid It

Welcome back to NINI’S SIMPLE GUIDE TO API SECURITY.

In the last edition, we looked at Server-Side Request Forgery (SSRF) and how attackers can use it to make a server send unintended requests. If you didn’t get a chance to read that one, here is the link.

Today, we continue the series by focusing on another important area of API security the management of API keys, tokens and other secrets. While SSRF focuses on request manipulation, this topic deals with something more straightforward: the risk of exposing the credentials that protect your systems and services.

In this article, we will explain how API keys and secrets commonly leak, why this problem is frequent in real development environments and the steps developers can take to avoid these mistakes.

What Are API Keys, Tokens and Secrets?

Although the terms are sometimes used interchangeably, they serve slightly different purposes:

• API Keys: These are identifiers used to authenticate requests to an API. They identify the application rather than the user.
• Access Tokens (OAuth Tokens): These are Bearer tokens that represent a user or application and grant specific permissions. Anyone who has the token can use it.
• Secrets: These are sensitive values such as API keys, tokens, private keys and passwords that must be protected.

The fact that these credentials often grant direct access to APIs, exposing them can lead to serious security loss and financial consequences.

Common Ways Secrets Leak

During research on GitHub, using terms like:

• API key
• token
• config.json
• .env
• secret_key

a clear pattern emerges. Many developers unknowingly commit sensitive data into public repositories. Even when they delete the file later, Git retains the history meaning the secret is still exposed.

Here’s where leaks typically occur:

1. Hard-coding credentials directly into code

Developers often test quickly and write lines such as:

const API_KEY = "sk_live_123...";

This might feel convenient, but once committed, the secret is exposed to the world and to bots that actively search for keys.

2. Committing .env and config files

Common culprits include:

.env
config.json
settings.py
appsettings.json

These files are meant to hold secrets locally, but when they’re pushed to repos, they become a goldmine for attackers.

3. Poor .gitignore hygiene

A missing or misconfigured .gitignore means sensitive files get tracked automatically.

4. Assuming “delete” removes the secret

A mistake many developers make:

• You delete a key from code
• Commit and push
• Think it’s gone

But Git history keeps everything. Meaning the secret can remain searchable even after removal.

Why These Leaks Matter

A leaked token can lead to:

• unauthorized access to APIs and databases
• billing abuse (e.g. cloud compute, SMS gateways, AI APIs)
• data exposure
• source code theft
• service outages
• reputation damage

Some leaked tokens have resulted in:

• attackers spinning up expensive cloud resources
• theft of intellectual property
• access to production environments
• compromised customer data

In short: a single leaked credential is a high-velocity attack vector.

What Tools & Attackers Look For

Secret-hunting bots scan GitHub for:

• sk- (often used by AI APIs)
• ghp_ (GitHub tokens)
• AIza… (Google APIs)
• AWS_ACCESS_KEY_ID
• TWILIO_AUTH_TOKEN

They search both:

• recent commits
• AND commit history

Meaning even temporary leaks become permanent risks.

How Developers Can Prevent Leaks

Never hard-code credentials

Use environment variables:

export API_KEY=...

Use a .gitignore

Add:

.env
*.config
*.pem

Use secret managers like:

• Vault
• AWS Secrets Manager
• Azure Key Vault
• GCP Secret Manager

Use automated scanners:

• Gitleaks
• GitGuardian
• TruffleHog
• Talisman

Run them before pushing code.

Rotate keys frequently

If a key is exposed:

• revoke it
• generate a new one
• update services

Avoid sharing credentials in:

• screenshots
• documentation
• Slack/Discord
• email

Understand that:

“delete” does not mean removed from history

To fully remove secrets from Git, rewriting history may be required not just deleting a file.

Key Takeaways

• API keys and tokens are leaked more often than developers assume.
• GitHub remains a major source of accidental exposure.
• Even deleted secrets may remain in commit history.
• Prevention requires intentional tooling and workflow habits.
• Security should be embedded into the development lifecycle not bolted on later.

Secrets are small pieces of data with massive consequences. Treat them like production passwords because that’s exactly what they are.

Final Thoughts

A single leaked API key can undo months even years of work. As developers and security professionals, we must normalize secure practices:

• keep secrets out of code
• automate detection
• rotate keys quickly
• use proper tooling

Accidental leaks happen, but with the right controls, they don’t have to.

The real mission is not just keeping secrets safe, it’s building an engineering culture where security is simply how we code, not something we remember after the push.