Lovable Apps Have a Security Problem Nobody's Talking About

To preface, I run a security auditing service that seeks to address the technical debt that comes from building with AI tools in order to give founders additional peace of mind prior to shipping. That said, last week I scanned a total of 8 lovable built apps, since I noticed that with the Lovable platform specifically that its vulnerabilities always seemed to be structured in the same exact way across different apps. Furthermore, many of these products had actual user bases and live billing mechanisms in place, and thus the data that these apps were handling were particularly important.

That out of the way, these are 5 of the most common findings that I came across among almost all of the Lovable built applications that i have audited thus far:

8/8 apps had at least one HIGH severity finding; though, typically within a short 10-15 minute window, I was able to source multiple (even within some of the better built products, same idea). Many of these findings were able to be sourced with fairly rudimentary tooling. For instance, almost all of the apps I scanned seemed to have secrets of all kinds baked right into the front end; accessible through DevTools alone. Things ranging from JWTs, API keys, etc etc. However, it gets worse:

2. 7/8 apps had a hardcoded supabase token sitting in the front in JS bundle sitting in plain sight. This being the code that your browser actually downloads first before loading your app, what this means is that anyone can open devtools on their local machine, and search for this directly within the sources tab with next to no effort. This key, plus an unprotected database means that anybody online can utilize this to grant themselves direct read/write access to your data without even being logged in.

3. 7/8 apps had no rate limiting mechanisms configured on login. What this means is that there is absolutely nothing stopping someone from attemptions thousands of password guesses on any account that they choose. Configuring an automation tool to cycle through common password lists to target specific users is simple, and what this means is that anyone can access any account they desire by running said scripts overnight. So thus, rendering user passwords completely useless as safeguarding mechanisms. Furthermore, on these same apps there was a complete absence of other such mitigation methods (ie: CAPTCHA trigger, account lockout/slowdown mechanisms), so this confirms that anybody can log in wherever they choose to on these sites completely under the radar.

4. 6/8 apps had their session tokens stored directly in localStorage. Essentially, when one logs into a session, the application receives a distinct user token that seeks to prove who you are. This token being stored in localStorage, what this means is that any malicious script running on the page (ie: a compromised dependency, ad, or pretty much anything at all) can both read the token and send it off to any destination an attacker chooses. Thus, in the attacker's case they are now the owner of this token and can use it to log into any site user they chose to for as long as the token's shelf life permits.

5. 5/8 were missing basic security headers entirely. In summary, security headers exist as sets of instructions that your server sends directly to your browser to tell it how it should behave with your information; so things like “block this content type”, "don't load resources from unknown domains”, “don’t allow this page to be embedded in iframe”, these act as parameters that need to be established to ensure your application is not exposed to certain exploits that it doesn't have to be. Without the presence of proper headers, this means that your app has no guardrails in place to prevent specific types of exploits; namely, clickjacking, cross site scripting, and MIME sniffing attacks become far easier to execute.

On the hardcoded key issue present in all scanned applications, this is a direct output structure produced by lovable apps specifically, since this is a known template default on the platform. For most founders, they are completely unaware that it is exposed like this to begin with.

As well, a few additional things that I found interesting:

One financial app handling personal banking data, business accounts, and bill payments had its Supabase key in the bundle with no rate limiting, and all table names leaking in the network tab. Being a fintech product, this is a fairly significant finding that leaves critical information readily exposed.
One platform advertising "enterprise security” and “end-to-end data protection" on its landing page had four high severity findings including email enumeration via a purpose-built endpoint and session tokens fully exposed client-side.
One B2B SaaS had 15 unauthenticated API endpoints. I wrote to their production database twice during the audit with zero authentication.

With all of these findings, none of the founders I have worked with even knew that these issues were present in their builds to begin with. If you've shipped with Lovable and haven't had anyone look it over, it is reasonable to assume that at least one of these applies to you.

4 comments