Protect Your Lovable Spreadsheet: We Audited 30 of Yours. Here Is What to Fix.
- Patrick Duggan
- 1 minute ago
- 5 min read
Earlier today we said your Lovable app was a spreadsheet wrapped in dark-mode CSS pointed at a Supabase free tier you had never logged into. That was the diagnostic post. This is the constructive one. We audited thirty of your spreadsheets and we are going to tell you, vector by vector, what your platform shipped with the brakes off, what is actually fine, and what you can do in the next twenty minutes to harden the thing without throwing the work away. The gap between a hackathon demo and a production deployment is not unbridgeable. It is fillable. Here is the fill.
We built two audit scripts. The first runs an eleven-vector AIPM pass against the URL itself, checking for security headers, cookie flags, CORS posture, HTTPS configuration, exposed dotfiles, stack-trace leakage, server identification, and secret patterns in the JavaScript bundle. The second targets the backend if there is one, parsing the JS chunks for embedded Supabase project URLs and anonymous keys, then probing the most common table names with the anonymous key to see whether row-level security is configured. Both scripts are passive, read-only, capped at one row per probe, and explicitly designed to confirm shape and stop. We sampled the first thirty URLs alphabetically from the lovable.dev discover feed on May 14, 2026.
The first thing we found is boring and universal and you can fix it without writing a single line of application code. Every single one of the thirty apps was missing the same three response headers. Content-Security-Policy. X-Frame-Options. Permissions-Policy. The CSP gap is the most material of the three because without a Content-Security-Policy any successful cross-site scripting injection has free run of the page. The X-Frame-Options gap mostly matters if your app has a login flow that a clickjacking attack could exploit, which most of the showcase apps do not, but if yours does you want this set. Permissions-Policy is mostly cosmetic on apps that do not use camera or microphone or geolocation. This is a platform-level default that Lovable could fix in one commit by adding the headers to the static hosting layer. Until they do, you can add a netlify.toml or _headers file to your repo and override the defaults yourself in five minutes.
The second thing we found is more interesting and it is the part where Lovable is doing better than the May 7 RedAccess report led us to expect. Six of the thirty apps had a Supabase backend detected in the JavaScript bundle. Five of those six embedded a usable anonymous key. Embedded anonymous keys are not a vulnerability. Supabase anonymous keys are designed to be public. The actual vulnerability check is whether the anonymous key returns row data on tables it should not return row data on, which is the row-level security question, and the answer in our sample was no. Zero of thirty apps returned actual rows when we probed the common table names with the anonymous key. Row-level security held across every backend we tested. We let the data say no, and we are saying so out loud because methodology integrity matters more than the dunk we expected.
There is one small information leak worth knowing about. When you probe a table name that exists but row-level security filters all rows, Supabase returns an HTTP 200 with an empty JSON array rather than a 404. That signal lets a scanner walk a list of common table names and confirm which ones exist in your project without ever reading a row. Four of our five backend apps leaked schema this way, surfacing the existence of tables named profiles, comments, messages, tasks, and subscribers. This is not critical and Supabase by design responds to anonymous schema introspection on tables the anonymous role has been granted execute on. But if your threat model includes adversaries who would benefit from knowing what tables you have, you can revoke the anonymous role from those tables and replace it with an explicit authenticated-role grant. Three lines of SQL.
The honest meta-finding is that the lovable.dev discover feed is curated. The RedAccess team scanned 5,000-plus Lovable, Replit, and Base44 apps and found 40 percent exposing data. That population is not the discover feed. That population is the long tail of self-published deploys that the platform does not promote. If your app is in the discover feed, congratulations, you are probably in better shape than the random Lovable deploy a scanner finds via a subdomain enumeration sweep. If your app is not in the discover feed, the risk profile is materially different and the eight-item checklist below is more urgent.
Here is what to verify on your own deployment before you call it a product, in priority order. One: open your browser developer tools, hit Network, reload your homepage, click your homepage response, and check Response Headers. If Content-Security-Policy is not present, you have a CSP gap. Two: if your app has a Supabase backend, open the Supabase dashboard, navigate to Authentication then Policies, and confirm that every table with sensitive data has at least one RLS policy that is not "true for all roles." Three: for any table with a public-write feature (waitlist signups, contact forms, public comments), confirm the policy is scoped to INSERT only and that SELECT is restricted to the row owner. Four: search your JavaScript bundle for the string "service_role" — anonymous keys are fine in the bundle, service role keys are not. Five: visit your-app-url-slash-dot-env in a browser and confirm it returns the same response as a random unknown path, not a real dotenv file. Six: open your repo and confirm your .gitignore excludes .env. Seven: if you have a real domain, set up Cloudflare in front of your Lovable deploy and turn on Bot Fight Mode plus a rate limit rule for the API path. Eight: write down the answer to the question "if this app got 10,000 sign-ups overnight from a TikTok mention, what would break first" — because the answer is almost always either Supabase free-tier connection limits or your email confirmation provider, and knowing which one ahead of time is the difference between fixing it in an hour and finding out the wrong way.
We will run the full audit script against one Lovable app URL for free on request. Email us the URL, we will run the eleven-vector pass and the Supabase RLS probe, and we will send you a report with severity-ranked findings and a remediation table. The script is named lovable-app-audit.js and the Supabase pass is lovable-supabase-audit.js, both in the open at our GitHub once we cut the public mirror, and both are deliberately written to be passive and slow and easy to read so you can run them yourself or hand them to your own AI to extend. The methodology mirrors the eleven-vector AIPM audit we run on a thousand-plus domains a month at aipmsec.com. The gap between hackathon and production is not unbridgeable. It is fillable. Now you have the fill.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.