How we helped make Lovable more secure

This is an incredible story of how we chained five low severity issues into a universal account takeover in Lovable. Part of the hack was done by exploiting vulnerabilities in Google (Firebase) and part - in Lovable. It resulted in finding a way to implant the code that could take over any Lovable user account that visits an infected link. After we reported it, Lovable fixed the problem in a matter of hours, and VIDOC helped them secure their product and development cycle.

Lovable had multiple layers of security in place:

Google's Firebase Authentication SDK
Content Security Policy (CSP) headers
CORS protection
Secure cookie attributes (HttpOnly, SameSite)
Mixed-content blocking

Yet we found a way to bypass them all and achieve complete account takeover. We exploited Firebase SDK's configuration system to redirect authentication traffic to our server, then used browser security features against themselves to capture user tokens.

... and we did it on a plane, flying over the Atlantic Ocean.

It's important to note that the Lovable team acted extremely quickly, fixing this vulnerability within 2 hours of our reporting, and that this exploit chain was never used by any untrusted party - all Lovable user data and projects remained safe.

What is Lovable and why we tested it

Lovable is the fastest growing startup - an AI platform that generates full-stack applications from text descriptions. Each generated app runs in an isolated sandbox with live preview.

This architecture is brilliant from a UX perspective: instant feedback, isolated environments, seamless integration. But from a security perspective, it's challenging. How do you safely sandbox arbitrary user-generated code while maintaining tight integration with your authentication system?

During our security assessment, we found the answer: you can't, unless you get the trust boundaries exactly right.

We discovered a vulnerability chain that turned Lovable's elegant architecture against itself, allowing complete account takeover of any user on the platform. This wasn't a simple XSS or CSRF - it was a sophisticated exploitation that weaponized browser security features, Firebase SDK internals, and Content Security Policy to hijack authentication flows in real-time.

This is the story of how we hacked Lovable, and how they became our customer and design partner.

How the attack worked

The attack exploited a fundamental architectural decision: sandbox apps lived on *.sandbox.lovable.dev, sharing the same effective top-level domain (eTLD+1) as the main application at lovable.dev. This seemingly minor detail cascaded into a full authentication bypass.

Here's the trust boundary problem visualized:

The vulnerability chain required chaining three distinct attack vectors:

Subdomain Cookie Injection: Exploiting browser cookie scoping to set configuration cookies for the parent domain
Firebase SDK Configuration Hijacking: Manipulating the __FIREBASE_DEFAULTS__ cookie to redirect authentication traffic
CSP-Based Mixed-Content Bypass: Using Content Security Policy to upgrade HTTP requests to HTTPS, defeating Firebase's built-in protections

Each vector alone was harmless. Combined, they created a privilege escalation ladder from "arbitrary content hosting" - "authentication backend hijacking" - "complete account takeover."

The result: user ID tokens, session data, and sensitive application metadata exfiltrated in real-time with full session persistence.

The five vulnerabilities we chained together

Understanding this vulnerability requires breaking down each component of the chain. Individually, these security decisions appear reasonable - even defensible.

1. Subdomain Cookie Scoping and the eTLD+1 Trust Boundary

The "fundamental" weakness: hosting user-controlled content on *.sandbox.lovable.dev under the same effective top-level domain (lovable.dev) as the main application.

Per RFC 6265 and the browser cookie specification, any subdomain can set cookies for its parent domain using the Domain attribute. Here's how cookie scoping works:

When a cookie is set with Domain=lovable.dev from abc123.sandbox.lovable.dev, that cookie becomes accessible to:

lovable.dev
app.lovable.dev
*.sandbox.lovable.dev
Any other subdomain under lovable.dev

This is by design in the cookie specification - browsers trust all subdomains equally within an eTLD+1 boundary. The Public Suffix List (PSL) exists precisely to prevent cross-organizational cookie setting (e.g., evil.co.uk can't set cookies for victim.co.uk), but it doesn't protect against same-organization subdomain attacks.

Security implication: Once an attacker controls any subdomain, they control the cookie jar for the entire domain. This is the foundational vulnerability that enables everything else.

2. Frame-Ancestors Policy Absence

The main Lovable application lacked both modern and legacy frame-embedding protections (according to Lovable team, this was done to facilitate sites embedding in third-party sites and enable better user experience):

No Content-Security-Policy: frame-ancestors 'self' header
No X-Frame-Options: DENY or SAMEORIGIN header

This meant any origin - including attacker-controlled sandbox subdomains - could embed https://lovable.dev in an iframe. While clickjacking is the typical concern here, the real danger in this context was different: it enabled the attacker to control the parent browsing context of a legitimate session.

Why this matters for CSP inheritance: When a page is embedded in an iframe, certain CSP directives from the parent frame can influence the child's behavior, particularly upgrade-insecure-requests. This became the linchpin of the mixed-content bypass.

3. Firebase SDK Cookie-Based Configuration

Firebase's JavaScript SDK includes a developer-friendly feature: configuration via the __FIREBASE_DEFAULTS__ cookie. This is documented behavior for local development and testing scenarios.

The SDK's initialization flow checks document.cookie for this magic cookie and parses it as JSON:

// Simplified from minified production code
function getDefaultsFromCookie() {
  const match = document.cookie.match(/__FIREBASE_DEFAULTS__=([^;]+)/);
  if (!match) return undefined;

  const decoded = atob(match[1]);  // base64 decode
  return JSON.parse(decoded);      // parse JSON config
}

The configuration object can specify:

forceEnvironment: Override environment detection
emulatorHosts: Object mapping Firebase services to emulator hosts
authTokenSyncURL: Custom endpoint for token synchronization

The design assumption: This cookie would only be set by developers during local testing. The SDK trusts this configuration implicitly once present.

4. Auth Emulator Redirection at Runtime

When emulatorHosts.auth is present in the configuration, Firebase Auth SDK performs a runtime redirect of all authentication traffic:

function getAuth(app = getApp()) {
  const auth = initializeAuth(app);

  const emulatorHost = getDefaultEmulatorHost('auth');
  if (emulatorHost) {
    // Redirects ALL auth operations to this host
    connectAuthEmulator(auth, `http://${emulatorHost}`);
  }

  return auth;
}

This function redirects:

Token refresh requests
User info fetches
Authentication state changes
Session validation

The security model: Firebase assumes emulator URLs are always http:// (localhost development), which would normally trigger mixed-content blocking in production HTTPS contexts. This is a reasonable guardrail - except when CSP manipulates the request.

5. Mixed-Content Bypass via CSP Upgrade-Insecure-Requests

This is where browser security primitives were weaponized. The attack flow:

Attacker's sandbox page at https://evil.sandbox.lovable.dev declares:

<meta http-equiv="Content-Security-Policy"
      content="block-all-mixed-content; upgrade-insecure-requests">

This CSP directive tells the browser: "For all descendent browsing contexts (including iframes), upgrade HTTP requests to HTTPS"
When the embedded https://lovable.dev iframe attempts to contact http://attacker.com (the emulator), the browser sees the parent's CSP policy and upgrades it to https://attacker.com
The request succeeds - mixed content protection is bypassed by design

The paradox: Firebase's http:// emulator requirement (a security guardrail) was defeated by a legitimate browser security feature (CSP upgrade).

The Chain Reaction

Each piece in isolation appears harmless or even security-positive:

Subdomain cookie scoping enables SSO and shared sessions
Embeddable apps increase integration possibilities
Cookie-based configuration simplifies developer experience
Emulator enforcement prevents accidental production leaks
CSP upgrade-insecure-requests hardens mixed-content protection

But when combined with an attacker-controlled subdomain, these features create a privilege escalation ladder from arbitrary content hosting to authentication backend hijacking.

Step-by-step: how we exploited it

Here's the complete attack flow, step by step. This exploit required no user interaction beyond visiting a malicious sandbox URL - everything else happened automatically.

Of course we won't show you the code, but diagram speaks for itself.

Why their security defenses didn't stop us

This attack is particularly interesting because it bypassed multiple security layers that were implemented correctly - they just weren't sufficient against this specific threat model.

CORS and Content Security Policy

Lovable implemented standard CORS policies and CSP headers on the main application. However, these protections operate at the network boundary - they prevent cross-origin reads and script injection.

This attack didn't need to fetch lovable.dev from the sandbox or inject scripts. Instead, it manipulated the application's own authenticated requests to target an attacker-controlled server. The application volunteered its secrets by design, thinking it was talking to a Firebase emulator.

The bypass: Instead of attacking the data flow, we attacked the configuration flow.

SameSite and HttpOnly Cookie Attributes

Modern cookie security attributes were properly implemented:

SameSite=Lax or Strict on session cookies prevented CSRF
HttpOnly prevented JavaScript access to sensitive cookies

But again, the attack didn't need to read existing cookies. We planted a new cookie (__FIREBASE_DEFAULTS__) that the Firebase SDK was designed to consume. The SDK read this cookie by design, not as an exploit.

The bypass: We didn't steal cookies; we injected configuration that the application trusted.

Firebase's HTTP-Only Emulator Requirement

Firebase's decision to require http:// emulator URLs is actually a clever guardrail. In normal circumstances, an HTTPS page (production app) attempting to contact an HTTP endpoint (emulator) would trigger mixed-content blocking - preventing accidental credential leaks.

However, CSP's upgrade-insecure-requests directive transformed this security feature into an attack vector. The browser automatically upgraded http://attacker.com to https://attacker.com, defeating the mixed-content protection while maintaining the illusion of local development.

The bypass: We weaponized a security feature (CSP upgrade) against another security feature (mixed-content blocking).

Defense-in-Depth Failure Mode

This is a textbook example of why security teams must think adversarially about feature interactions. Each defense was sound in isolation:

Proper CORS/CSP implementation
Secure cookie attributes
Mixed-content protection via HTTP enforcement

But the attacker didn't need to break any of these - they found a path around them by exploiting the trust assumptions between components.

What happened after we disclosed it

Finding and fixing this vulnerability was just the beginning. The real value came from establishing a continuous security partnership. Here's what happened after disclosure:

The Response

When we disclosed this vulnerability to Lovable, their response was exemplary - they fixed the vulnerability within couple of hours. Lovable performed extensive analysis of logs and telemetry and confirmed that except for VIDOC researchers, this advanced exploit chain has never been used by any untrusted parties, and all user data and projects remained safe.

The Partnership

Lovable became a VIDOC design partner and customer. Their engineers are AI-enabled, using the latest AI models to ship code at unprecedented speed. At that velocity, traditional security testing can't keep up.

That's where VIDOC comes in. The VIDOC application automatically secures every code change they deploy. VIDOC finds security issues that previously only human security experts could catch - but we do it instantly, on every commit. This lets Lovable maintain their lightning-fast development pace without compromising security.

Key lessons from this vulnerability

This vulnerability teaches us several important lessons about modern web security:

0. The right architecture can prevent disaster - or cause one - especially in multi-agent, complex systems.

This vulnerability was ultimately an architectural issue, introduced only days before we found it. The technical sophistication of the exploit chain shows that:

Early architectural decisions have cascading security implications.
You can’t be secure against all threats, but the right architectural choices can significantly reduce impact.
Human reviews of single PRs are not enough at large scale.

1. Domain separation matters

The fundamental issue was hosting user-controlled content on the same eTLD+1 as the main application. If you're building a platform with user-generated content or sandboxes:

DO: Use a completely separate domain (e.g., *.customerusercontent.com)
DON'T: Use subdomains of your main domain (e.g., *.sandbox.yourapp.com)
CONSIDER: Requesting PSL entries for additional isolation

2. Multiple security layers are required

Every security control in this chain was present - CORS, CSP, cookie attributes - but they weren't sufficient. Real security requires:

Multiple overlapping controls
Adversarial thinking about feature interactions
Regular security assessments from external experts

3. Third-party SDKs can be exploited

Firebase's cookie-based configuration was designed for developer convenience, but became an attack vector. When using third-party SDKs:

Audit configuration mechanisms in production
Disable development-only features in prod builds
Validate that SDK behavior matches security assumptions

4. Security features can backfire

CSP's upgrade-insecure-requests is a security feature that we weaponized. This is a reminder that:

Security features have complex interactions
What protects in one context can enable attacks in another
Testing must include adversarial scenarios

Conclusion

This blog post isn't just about a cool vulnerability chain - though it was pretty cool to find and exploit. It's about what happens after you find the bug.

We could have written this as a typical vulnerability disclosure: "We found X, they fixed Y, case closed." But that's not the interesting story.

The interesting story is that Lovable recognized security isn't a checklist to complete - it's a continuous process. They didn't just patch the bug; they partnered with VIDOC to build security into their development lifecycle.

For developers building on modern platforms: This case study shows why architectural decisions matter. Subdomain isolation, frame-ancestors policies, and SDK configuration might seem like minor details, but they're the building blocks of your security posture.

For security engineers: This demonstrates the value of chain exploits in security assessments. Individual vulnerabilities might be rated "low" or "informational," but the chain was critical. Look for interaction effects, trust boundary violations, and SDK assumptions.

For companies building platforms: Lovable's response - moving from disclosure to partnership in days - is the model for modern security. Continuous monitoring, automated testing, and expert guidance aren't overhead; they're competitive advantages that let you move fast without breaking things.

If you're building a platform with user-generated content, Firebase authentication, or complex trust boundaries, we should talk. VIDOC specializes in finding these architectural vulnerabilities before attackers do - and helping you build security into your development process.

Because the best time to find a critical vulnerability is before it's exploited in the wild.

Want to secure your platform like Lovable did? Contact VIDOC for a security assessment.

Are you a security researcher? We're always looking for creative vulnerability chains. Join our research team.