Learn

#basics#env#API keys

Security basics: what's actually dangerous about .env and API keys

A first step for indie developers who keep hearing 'security matters' but don't know where to start. What .env is, what happens when an API key leaks (with a flow diagram), and the minimum four habits you can do today — explained plainly, without fear, hands-on.

Published 2026-06-07 Updated 2026-06-07 4 min read

"I keep hearing security matters, but where do I even start?" This is the very first step for indie developers. Not to scare you — only things you can act on today, in order.

Why start with "secrets"

Most real incidents begin not with sophisticated attacks but with a leaked secret. The two cases ITD is built on were both secret leaks:

Protect your secrets and you prevent most common incidents. So we start here.

What `.env` is (in 30 seconds)

.env is a file that gathers your app's secret values: the database password, external API keys, the key that encrypts sessions. Because the keys sit together in one file, a leak spills all of them at once — so it's the file to guard first (→ Glossary: What is .env).

What an API key leak means

An API key is "a spare key to use a service as you." In the wrong hands, it chains like this.

① The API key leaks (public dir, git commit, or via a vulnerability)

↓ on a delay (days+)

② A third party uses the external service "as you"

↓

③ Fraudulent billing / data read-write / impersonation

Quiet at first. Abused on a delay — then one day a bill or breach surfaces.

Stolen keys are often resold and abused on a delay — "nothing happens at first, then a surprise bill" is the classic pattern. So "after you notice" is too late; the point is to not leak them in the first place.

Four habits to start today

Nothing hard. Just these four.

Don't expose it

Never place .env or the app body in a web-visible directory (the web root). Expose only public/. Concrete steps for shared hosting: this guide.

Don't commit it

Add .env* to .gitignore (allow !.env.example); share only a value-less example. Once committed it's recoverable from history, so keep it out from the start.

Rotate everything if leaked

Not just one key — rotate every secret that could have leaked. Order: external API / OAuth → encryption keys → mail → DB. Act as if seen.

Self-check

Occasionally confirm /.env can't be opened from the outside (below).

Self-check (only against domains you own)

# A 200 with a body means it's exposed. 403/404 is okay for now.
curl -sI https://your-domain/.env | head -1
curl -sI https://your-domain/.git/config | head -1

Checking this on every deploy catches placement mistakes early.

Common mistakes vs the right first step

Common

"It works", so drop .env right under public
"I'll delete it later", so commit .env once
Rotate only the one key you saw abused

The right first step

App body outside the web root, expose only public/
Exclude .env via .gitignore from the start
If it leaks, rotate every secret in the env

Next steps

From here, the next topics are "the risky defaults in your stack" and "a system to not fall behind on published CVEs." No rush, one at a time.

FAQ

QWhere should I start with security?

With not leaking your secrets (.env and API keys). Most real incidents start there. Don't expose them, don't commit them to git, rotate everything if they leak, and self-check occasionally — that prevents the majority.

QWhat concretely happens if an API key leaks?

Someone can act as you against an external service. The common outcomes are fraudulent billing (heavy usage charged to you) and reading/writing your data. Stolen keys are often resold and abused on a delay.

QCan I put .env in git?

No. Add .env* to .gitignore and share only a value-less .env.example. Once committed, it can be recovered from git history even after you delete it later.