.env File & Exposed Secrets
A .env file stores an app's secrets — API keys, database passwords, tokens — separately from the code. It must never end up in the browser and never be committed to the Git repository. Exposed secrets are one of the most common and most expensive weaknesses in AI and no-code apps: a single leaked key is enough to read databases, run up someone else's bills, or harvest user data.
The point of a .env file is separation: secrets live outside the code so they aren't published by accident. That separation breaks in two ways. First, server-side: the .env gets committed to the Git repo — then every key sits permanently in the history, even after deletion. Second, client-side: a secret is pulled into the browser bundle via a NEXT_PUBLIC_ or VITE_ prefix and is readable by anyone.
Why this is so expensive: a key is not a password only one person knows — it is a power of attorney. A leaked Stripe key can trigger real payments, a cloud key can spin up real servers (that you pay for), a database password opens the entire dataset. Unlike a bug, a leak often goes unnoticed for months — until the bill or the data breach arrives.
How you check it: .env files belong in .gitignore and must never appear in the repo; production servers (e.g. .env at the web server or /.git) must not be reachable from outside; and no real secret may sit in the browser bundle. Our Rescue scan probes from the outside for openly reachable .env and .git paths, and in the deep scan checks the repository for committed secrets — Stripe, AWS, GitHub, OpenAI, and database keys.