Secrets in code — how to avoid giving hackers the keys to your server

Imagine this scenario: you’ve been working on a cool project all night. By 4 a.m. everything is ready, you do a final git push and go to sleep with a clear conscience. In the morning you find your AWS balance is zero and a miner is running on your servers. What happened? It turns out you left a line in one of the files: AWS_ACCESS_KEY_ID = "AKIA...".

This is a classic mistake thousands of developers have made. In this article we’ll look at why “just deleting the password” won’t help and how to set up automatic protection that will physically prevent you from making the mistake.

What are “secrets” and why is this a problem?

In development, secrets are any data that grant access to protected resources:

• Database passwords.
• API keys (Stripe, OpenAI, AWS, Telegram bots).
• Private SSH keys.
• Authorization tokens.

The main problem: developers often treat code as a draft. “I’ll paste the key here now to check if the integration works, and before deploy I’ll move it to environment variables.”

But Git doesn’t work that way.

The myth of deletion

Git is a version control system. Its primary job is to remember everything. If you committed a file with a password and two hours later removed it and made a new commit — the password didn’t disappear. It remained in the history. Anyone who clones your repository can revert to the earlier commit or simply look through git log and see your key.

Hackers don’t sit and manually browse repositories. They have scanner bots that monitor the public commit stream on GitHub 24/7. As soon as a key hits the network, it often ends up in an attacker’s database within minutes — sometimes within 20–60 seconds.

First line of defense: the “no secrets in code” principle

Before moving to tools, adopt a rule: code should be public by default. Even if you’re writing a private project, write it as if you’ll publish it as open source tomorrow.

Using .env files

The simplest way is to store settings in a .env file that never goes into Git.

1. Create a .env file.
2. Add your keys there: DB_PASSWORD=my_super_secret_password.
3. In code use libraries (for example, dotenv for JS/Python) to read these values.
4. Critically important: add the line .env to your .gitignore file.

Automating protection: introduction to Git hooks

We’re human, and we make mistakes. To eliminate the human factor, we need robots that will stop us before a commit is made. For this there are Git Hooks.

Hooks are scripts that Git runs automatically on certain events (for example, before a commit or before a push).

Tool #1: Gitleaks

Gitleaks is one of the most popular and fastest secret scanners. It looks for matches across a huge pattern database (formats for AWS keys, Google Cloud, Stripe, etc.).

How this works in practice

Installation:
If you have Homebrew (macOS/Linux):

brew install gitleaks

Or you can download the binary from GitHub (Releases) for Windows/Linux/macOS.

Manual scan: You can run a scan of the entire project right now:

gitleaks detect --verbose

If there are forgotten keys in your project’s history, Gitleaks will list them with the exact lines and files.

Tool #2: pre-commit (a framework for the lazy)

To avoid running the scan manually every time, we use the pre-commit framework. It automates running Gitleaks on every attempt to run git commit.

Setup instructions

1. Install pre-commit:

pip install pre-commit

2. Create a file .pre-commit-config.yaml in the project root.

3. Add the following lines:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.0  # Используйте актуальную версию
    hooks:
      - id: gitleaks

4. Install the hook into your system:

pre-commit install

What will happen now? When you run git commit -m "added login logic", Gitleaks will automatically run. If it finds a secret, it will abort the commit and print an error. You simply won’t be able to commit dangerous code. This is the concept of “secure by default”.

What to do if a secret has already been leaked?

If you discover that a key has been leaked to a public repository, the course of action should be:

1. Revoke the key: this is the most important step. Don’t try to just delete it from Git. Assume the password is known to everyone. Go to the management console (AWS, Google, Telegram) and deactivate the key. Create a new one.
2. Clean the history: if you truly need to remove traces from the repository, use BFG Repo-Cleaner or the built-in git filter-repo command. Ordinary git rm won’t help.
3. Rotate all related access: if a DB password leaked, change it everywhere it was used.

Summary for beginners

Dealing with secrets isn’t about complex algorithms; it’s about discipline and the right tools.

• Never write passwords directly in code.
• Use .env and .gitignore.
• Set up Gitleaks via pre-commit once, and it will save your career (and your wallet) in the future.

Remember: it’s better to be overcautious in security and spend 15 minutes setting up hooks than to spend a week recovering hacked infrastructure.