Original Summary

I build a code scanner for AI-built apps. This month I pointed it at 70 public Lovable repos and then read every serious finding by hand, mostly because I didn't trust my own tool. Good call. It flagged 326 things. I threw out 183. Hardcoded fetch hosts it thought were user-controlled, policies that a later migration had already dropped, public anon keys it matched as secrets. I fixed those rules between the two batches, which was humbling. What survived: 28 of the 70 had something actually serious in their own code. The other 42 were fine, which surprised me more than anything else. The serious stuff was almost all in two places. First, Supabase edge functions with verify_jwt off and nothing checking the caller instead. 19 of the 33 apps using edge functions had at least one. One renewed and charged subscriptions, one ran a data purge, one recorded signed contracts for whatever customer ID you sent it. Anyone with the URL could call them. Second, RLS turned on but a policy with using (true) on insert or update, which means RLS is on and does nothing. 14 of 47 apps with a database. Things that were not a problem, contrary to what I expected: RLS was enabled almost everywhere, and almost nobody committed a real secret. 69 of 70 have a dependency CVE, but it's the vite version the template ships, not something the builders did. lovable fixed it with the new tanstack build tooling. If you've got a Lovable app with edge functions, the one thing worth checking is: for every function with verify_jwt = false, what does it check instead? If the answer is nothing, that's the bug. Write-up with methodology and the raw numbers is here if you want it: https://ascertify.io/lovable-security-report . Owners were notified before publishing, nothing is named.   submitted by   /u/FullConfidence7298 [link]   [comments]

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/9/24 20:14:33