Security

How VibeSafe Builder protects your code and your credentials

We're built by the same team behind VibeSafe, a code security scanner — this is the same instinct applied to the builder itself, not just the apps it generates.

Contents

  1. Every build is scanned
  2. Launch Check — real-browser validation
  3. Your API key and session
  4. Published apps
  5. Database and access rules
  6. Payments
  7. Report a security issue

01Every build is scanned

Every generation is checked for hardcoded API keys and secrets, eval() and dynamic code execution, insecure http:// resources, passwords written to localStorage, and data sent to unrecognized third-party servers. This runs automatically in the builder's Security tab, and is enforced again server-side before anything can be published — a bypassed or stale client-side result can't slip a critical issue onto a public link.

02Launch Check — real-browser validation

A static scan reads code; it doesn't run it. Launch Check does — it loads your app in a real headless browser and checks for uncaught exceptions, console errors, and mobile-layout breaks that only surface when the app actually executes. This is combined with the security scan in the builder's Build Health tab for one overall verdict.

03Your API key and session

In Bring Your Own Key mode, your Anthropic API key lives only in your browser's local storage and is sent directly from your browser to our server per request — we never log or store it. In Managed mode, your session comes from Supabase magic-link sign-in; we never see or store a password. Neither is ever embedded in an app's code — the model is instructed never to hardcode credentials, and the security scan blocks publishing if it tries. The live preview you see while building runs in a sandboxed frame with no access to the builder's storage. Published apps currently run on the same domain as the builder, so we scan every publish for code that tries to read the builder's storage and apply a restrictive Content-Security-Policy limiting where any data could be sent — we're completing further isolation for published-app hosting on top of that (see below).

04Published apps

Publishing re-runs the security scan server-side before anything goes live, blocking known-dangerous patterns regardless of what the client showed. Published pages are also served with a restrictive Content-Security-Policy limiting what they can connect to. We're in the process of moving published-app hosting to its own isolated domain, separate from the builder itself — the same approach code-sandboxing platforms like CodePen and Replit use — as an additional layer on top of the scan.

05Database and access rules

Every table VibeSafe Builder writes to — published apps, subscriptions, and managed-plan usage records — uses Row Level Security, which we verified directly against the live database rather than assuming it. The service-role key that can bypass those rules is never sent to a browser; it's used only in server-side webhook and billing code.

06Payments

Managed-plan billing is handled entirely by Stripe. We receive a webhook confirming your subscription is active — never your card number or CVC. Stripe webhook signatures are verified on every call, so a request can't be forged into activating an account. BYOK has no platform fee, so no payment information passes through us at all.

07Report a security issue

Found something? Email security@vibesafebuilder.com with what you found and how to reproduce it. We'll acknowledge real reports and won't take action against anyone testing in good faith against their own account or data. Please don't test against other users' published apps or accounts.