Leaked API Keys and Secrets: GitHub, .env and Frontend Leaks, Their Effects and Prevention
When an API key, database password or secret token stays embedded in code or accidentally leaks to GitHub, a frontend bundle or a backup, attackers find it within minutes. The result can be your cloud account being taken over, a data breach and high bills. We explain how leaked keys are found, their effects, and how to prevent them with secrets management, with sources.
Leaked API Keys and Secrets: GitHub, .env and Frontend Leaks, Their Effects and Prevention
Quick answer: A secret leak is an API key, database password, secret token or private key ending up somewhere accessible. It most often leaks from three places, first being embedded in code and pushed to a code repository like GitHub, second being embedded in the frontend (browser) bundle or a mobile app, third the exposure of a backup, a log file or a misconfiguration. Attackers do not search for these keys by hand, they find them within minutes with bots that automatically scan GitHub and the wider internet. The effect is severe, with a leaked cloud key an attacker can take over your servers, read your database or run up high bills in your name. The way to prevent it is three principles, never embedding a secret in code (using a secret vault or environment variable), auditing the repository and bundles with secret scanners, and, if a secret leaks, immediately revoking and replacing it (rotation).
Modern applications connect to dozens of external services, payment, email, cloud, artificial intelligence. Every connection needs a key, and these keys are the application's most valuable secrets. Leaking a key is like leaving your house key on the street. We covered the holistic security audit of source code and where secret scanning fits in source code security audit, SAST, DAST, SCA. This article focuses specifically on secret leakage, one of the most common and cheapest vulnerabilities to exploit.
Where secrets leak from
Secret leakage has a few classic sources and all of them are preventable.
- Code repository (GitHub, GitLab). A developer writes the key directly in the code for speed and then pushes it to the repository. If the repository is public the key is instantly visible, and even if it is private it stays in the git history and surfaces in a breach.
- Frontend bundle. Any secret embedded in JavaScript running in the browser can be seen by the visitor, because everything that reaches the browser is open. A secret key should never be placed in the frontend.
- Mobile app (APK). A key embedded inside a mobile app can be extracted when the app is opened with reverse engineering.
- Backups, logs and configuration. A database backup, a log file or a wrongly permissioned .env file can expose secrets.
How attackers find leaked keys
The critical truth is, attackers do not search for these keys one by one by hand. Automated bots that constantly scan GitHub and the wider internet look for specific key formats (for example cloud providers' key patterns) and use them within seconds when they find a match. So when a key is accidentally pushed to a repository, even if you delete it a few minutes later, the bot may already have found it. Once a secret has leaked, it is no longer secret, the only safe path is to revoke it.
Effects, what a single key costs
The effect of a leaked key depends on what that key can access, and is often heavier than assumed.
| Leaked secret | What the attacker can do |
|---|---|
| Cloud provider key | Take over servers, delete data, run up high bills in your name |
| Database password | Read, alter, delete all customer data, data breach |
| Payment provider key | Fake transactions, interfere with money flow |
| Email service key | Send bulk phishing mail in your name |
| AI API key | High usage bill in your name, quota exhaustion |
| Admin token | Full access to the system, a persistent backdoor |
A leaked cloud key alone can lead to a data breach capable of ending a company. If personal data is involved this is a breach under KVKK and requires notification, we explained the process in KVKK data breach notification, 72 hours.
How to prevent it, three principles
1. Never embed a secret in code. Keys must be kept separate from code. On the server side use environment variables or a secret manager (vault). No secret key is ever placed in the frontend, secret operations are always done on the server side.
2. Scan the repository and bundles. A secret scanner automatically searches for leaked key patterns in the code repository and in compiled bundles. Platforms like GitHub offer built in secret scanning, and by adding a scanning step to your build pipeline you can catch secrets before they enter the repository. This is a natural part of source code auditing.
3. If it leaks, revoke and rotate immediately. If a secret has leaked, the most important step is to immediately revoke it and replace it with a new key. Regularly rotating keys and giving each key only the narrowest privilege it needs (the principle of least privilege) limit the impact of a leak.
Deleting a leaked key from the repository is not enough, because it remains in the git history and has probably already been copied. A leaked key must always be revoked.
What to do after a leak
If you notice a key has leaked, in order, immediately revoke the leaked key, create and deploy a new key, examine the systems reached with that key for suspicious activity, and clean the git history. Understanding whether an attacker used the key is a forensic examination, unauthorized access is searched for in the logs. We covered the forensic side of account and system takeover in account takeover.
Frequently Asked Questions
I deleted the key from the repository, am I safe? No. The key stays in the git history and has probably already been copied by automated bots. The only safe path is to revoke the key and replace it with a new one.
I have to put an API key in the frontend, what should I do? A secret key should never be placed in the frontend. Move secret operations to the server side, let the frontend talk only to your server, and keep the secret key only on the server.
Is keeping a key in a private repository safe? No. Private repositories can also leak, someone with access can leave or the account can be compromised. Secrets should be kept in a secret vault or an environment variable, not in the repository.
Did the attacker use the leaked key, how do I know? In the logs of the system reached with that key, unexpected access, unusual regions and atypical usage are searched for. This is a matter for forensic examination.
Sources
- OWASP, Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- CWE-798, Use of Hard coded Credentials: https://cwe.mitre.org/data/definitions/798.html
- GitHub, secret scanning documentation: https://docs.github.com/en/code-security/secret-scanning
- NIST SP 800-57, key management recommendations: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
To scan for leaked keys in your code and bundles, investigate a leak and set up secrets management, contact DSET.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.