Lovable
Auth misconfiguration 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.
The public clues this scan can see, not a login test.
What the scan can see
Cookie flags (Secure, HttpOnly, SameSite) when a cookie is set, wildcard CORS, and secrets in the client bundle. A service_role key or a session secret in JavaScript is an auth problem because anyone who loads the page can copy it.
What it does not do
The scan does not try passwords, bypass a login, reuse a session, or call your auth provider. It cannot tell you that a rule allows the wrong user.
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
Keep session cookies HttpOnly and Secure. Keep privileged keys on the server. Review who your auth rules allow, in the provider's console, because this scan will not do that review.
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 auth misconfiguration is fully fixed?
The scan does not try passwords, bypass a login, reuse a session, or call your auth provider. It cannot tell you that a rule allows the wrong user.
What should I do if the scan finds it?
Keep session cookies HttpOnly and Secure. Keep privileged keys on the server. Review who your auth rules allow, in the provider's console, because this scan will not do that review.
Scan a URL you own
The same free check as the homepage. You confirm the app is yours before it runs.