Lovable: files you deployed by accident

This category is unglamorous and disproportionately damaging. Nobody chooses to publish their environment file; it happens because a file sat in the wrong folder and the whole folder got deployed.

What tends to leak from a Lovable project

• Source maps (.js.map) — these turn your minified bundle back into original, commented source. Your logic, route names and auth flow become readable.
• Environment files (.env, .env.local, .env.production) — if one lands in the public folder it is served like any other file.
• Backups and dumps (backup.sql, db.sql) — a full copy of your data, downloadable.
• Editor and OS leftovers (.DS_Store) — lists the filenames in a folder, defeating any security-by-obscure-filename.

Check it yourself, two minutes

for p in .env .env.local .git/HEAD backup.sql .DS_Store; do
  printf "%-14s " "$p"
  curl -s -o /dev/null -w "%{http_code}\n" "https://YOURAPP.com/$p"
done

Every line should print 404. A 200 means that file is public.

Audit what my deployment actually serves and remove what should not be there.

1. Check whether any of these are reachable in production and fix each:
   .env, .env.local, .env.production, .git/, backup.sql, .DS_Store,
   any *.map source map file.
2. Ensure environment files live outside the public/static directory and
   appear in .gitignore and .dockerignore.
3. Disable production source maps in the build config.
4. Add a rule that returns 404 for any path starting with a dot.

Then tell me which of these were actually exposed before the change. For
each one that was, list the credentials it contained so I can rotate them —
assume anything that was public has already been collected.