5 API Calls Exposes Every Lovable Project Built Before Last November

For those of you who are not familiar with Lovable, it is a low code or maybe no code development platform that you can talk to and it will create a web application for you in minutes. It has become the darling of the development community and went from zero to a $6 billion valuation since November 2024.

The vulnerability, apparently, is still exploitable for projects created before last November and Lovable’s handling of the exploit is a model in how NOT to respond to something like this.

The simplified version of the bug is that Lovable checked to make sure you were a valid user when you made a request (a free account qualifies) but did not check if you had permissions to the project that you are making the API call for.

THIS BUG, CALLED BROKED OBJECT LEVEL AUTHORIZATION or BOLA is OWASP’s #1 on its API security top 10.

So what do you get if you exploit this?

• Full source code – including any passwords in your code
• Database credentials – pretty clear what that does
• Complete AI chat history – every prompt and every response between the platform and the developer
• Any customer data stored in connected databases
• Internal AI reasoning logs – how the model determined what the code should look like.

Here is where Lovable went sideways when they tried to do the spin doctor thing.

First they said ” to be clear, we did not suffer a data breach”. Technically, I guess, true since the user was an authorized user, but in practice, nah, I don’t think that flies.

Then they said the documentation should have made it clear, so us bad, we should improve the documentation.

Finally, and all of this happened inside one day, they blamed Hacker One, who handles their bug bounty program, claiming they determined that the bug as reported was expected behavior.

The company switched to “private by default” last December, but then undid that in February. Common problem. Not clear how that happened, but apparently someone made a change on the back end and did not understand the impact.

This is not uniquely a Lovable problem. Their target audience in non-programmers. They don’t know what they don’t know and especially, they don’t understand security. They assume that Lovable is protecting them, which they absolutely are not. Which is why I say this is not really a “no coding” tool, meaning you just talk to it and it does all the work, but rather it is a “low code” tool, meaning it does a lot of the heavy lifting but you better look at the result to make sure it is ONLY doing what you think it is doing.

By default, if you use Lovable’s built in database, the database credentials are hardcoded into the source code. If that code is visible on the Internet, so is all of your data.

If you use Lovable, you need to review each project created prior to December to make sure that there are no hardcoded credentials in them.

But here is an interesting question. If you use AI to develop or enhance your programs, who is responsible for bugs. That includes if you are a non-technical user of vibe coding tools like Lovable.

HINT: It is not the AI’s responsibility to make sure your code and your data is secure.

Lovable is still trying to put out the dumpster fire they created, so if you have old projects, no matter whether you have made updates recently (updating a project does not eliminate the vulnerability), it is time to change passwords to resources used by the project.

If you need assistance, please contact us.

Credit: Breached Company

by