Critical severity · Lovable

Exposed .env file on Lovable

Your .env file is reachable from the public internet. This is the worst-case scenario: .env files hold database passwords, API keys, Stripe secrets, and service-role tokens. Anyone who finds it can impersonate your backend. The fix depends on where it is served from — usually it means adding `.env*` to your static-host ignore list or redeploying without the file in your build output. Rotate every secret immediately.

The fix for Lovable

Lovable

Lovable sometimes writes env vars to files in the public directory when it doesn't have a proper env system. Search your project for files containing your API keys and delete them. Move secrets to Lovable's env var UI.

Why it matters

Attackers run automated scanners against every new domain for `/.env`, `/.env.local`, `/.env.production`. If you shipped one by accident, someone has found it within hours. Every secret inside is compromised — no exceptions.

Confirm the fix worked

Scan your Lovable site to confirm this finding is gone.

AI prompt

Apply across your codebase

Paste this into Cursor, Lovable, Bolt, v0, or Claude Code.

My deployed app has a .env file accessible at https://my-site.com/.env. Find where it is being copied into the build or deployment and remove it. Then search my codebase for every secret in that file (database URL, API keys, service role tokens, Stripe keys) and tell me which ones I need to rotate. Also update .gitignore, .vercelignore, and any build config to exclude .env files going forward.

FAQ

Frequently asked questions

I rotated the leaked keys. Am I safe?
Mostly. Check your logs for any activity using the old keys — if someone used them, they may have created persistence (new user accounts, webhook URLs, storage buckets). Audit access lists on every service whose key was leaked.
Why does this keep happening with AI-built apps?
AI tools sometimes treat .env as regular config and write it to the source tree, or build tooling copies everything in the project root to the output. The fix is always: env vars live in the host's env UI, never in a file shipped to production.