Lovable
Exposed .env files on a Lovable app
Lovable turns a chat into a hosted app. The preview URL and the production URL both serve HTML and JavaScript to anyone who opens them. Variables that the framework marks as public, and secrets pasted into a client component, travel with that bundle.
Public env files and why source maps are a separate problem.
What the scan can see
One GET each for /.env, /.env.local, and /.env.production. A body that looks like assignment lines is a critical finding. An HTML app shell at those paths is not treated as a leaked env file. /.git/HEAD and /.git/config are checked the same way.
What it does not do
Source maps (.js.map) are not requested. A map file can reveal original source, and this scan will not tell you if one is public. Local env files that were never deployed are also invisible.
A scan of a Lovable URL does not open the Lovable project, the chat history, or env vars that stayed on the server. If the browser never downloaded it, this check will not see it.
What to do next
If an env file was public, rotate every secret that was in it. Configure the host so those paths 404. Do not publish source maps for a production bundle.
Questions
Does this open my Lovable project?
No. A scan of a Lovable URL does not open the Lovable project, the chat history, or env vars that stayed on the server. If the browser never downloaded it, this check will not see it.
Can the scan prove exposed .env files is fully fixed?
Source maps (.js.map) are not requested. A map file can reveal original source, and this scan will not tell you if one is public. Local env files that were never deployed are also invisible.
What should I do if the scan finds it?
If an env file was public, rotate every secret that was in it. Configure the host so those paths 404. Do not publish source maps for a production bundle.
Scan a URL you own
The same free check as the homepage. You confirm the app is yours before it runs.