Security Review for Vibe-Coded Projects: take AI code live safely
With Lovable, Cursor or Claude Code, an app takes shape in days. Nobody checks its security. Often every visitor can see the data. Before go-live we review the code, database, running app and data protection. After five or ten working days you receive a report with fixes for your tool.
Agreed fixed price from CHF 3'900Fixes as a prompt or code diffReport from 5 working days
Free and non-binding · 30 minutes · confidential under NDA · read access and test accounts are enough
Law and technology from a single engagement: code review, RLS test and data protection launch checklist in one report.
For founders, SMEs, agencies and investors
Report from 5 working days
Launch Check 5, Go-Live Review 10 working days
RLS, secrets, auth checked by hand
OWASP Top 10:2025, beyond the scanner
Dr. iur., LL.M., CIPP/E
Data protection launch check under the FADP and GDPR
Confidential, reviewed in Switzerland
NDA, duty of confidentiality, no copy of your code held by third parties
Technical lead for this engagement
Oliver Stutz
Co-Founder · InfoSec & Cybersecurity Expert · Bachelor of IT (Bond University)
Oliver Stutz is Co-Founder and leads the SIDD development centre for technical information security and cloud security. He builds with generative AI himself. His team reads your code, tests the running app and writes the fixes. They are joined by the team of Dr. Dominic Staiger, LL.M., Dr. iur., CIPP/E, Attorney at Law (New York) and Solicitor (UK). It handles the data protection launch checklist.
What is a Security Review for Vibe-Coded Projects?
Brief definition
The Security Review for Vibe-Coded Projects checks AI-written apps for security and data protection under the FADP and GDPR. We review the code, the settings and the running app. The benchmark is the OWASP Top 10:2025, the list of the most common web vulnerabilities. For each finding the report gives the severity, steps to reproduce and a fix. It is also called a vibe-code audit or AI code review.
Andrej Karpathy coined the term vibe coding in February 2025: you follow the AI and no longer read the code. The code is written in hours and passes the tests. But nobody checks its security.
Here the browser usually talks directly to the database. Every visitor can see the public key for it. The only protection is the RLS policy: a rule on who may see which table row. If it is missing or wrong, anyone can read and write data. The review therefore answers three questions: Who may do what? Where are the keys? What happens to the personal data?
Do you need a Vibe-Coding Security Review?
The review pays off for any AI app with real personal data, payments or external users. From 09.12.2026 the new EU product liability regime (Directive (EU) 2024/2853) also covers software newly placed on the market. After launch, every finding costs more: rotating keys, informing customers, possibly notifying the breach.
1
Go-live with customer data, login or payments: From the first personal data record, the FADP and the Data Protection Ordinance (DPO) apply. Before launch you clarify: Can other users read data? Is the service key, the master key to the database, in the browser code?
2
An enterprise customer, an investor or your agency client asks: A security questionnaire or due diligence calls for a named reviewer with a legal assessment. The platform's scan is only a start.
3
An internal tool with HR or financial data: Employees build it without IT. In May 2026 RedAccess found around 380'000 publicly reachable vibe-coding assets, roughly 5'000 of them without login protection. The inventory and rules come from the AI Governance Check.
4
An incident or a warning: A security researcher or Supabase reports open tables. We then clarify: How far did the access reach? Is a notification due to the FDPIC or an EU supervisory authority?
5
The app has AI features: The AI key often sits in the browser with no spending limit. Since 02.08.2026 the EU AI Act has required chatbots for EU users to disclose that they are AI. We check this too. For agents in production we recommend the deeper AI security assessment.
What makes us unique
Three disciplines for code written by an AI
Our engineers review the code and our lawyers give every finding a legal assessment. Neither a pure law firm nor a conventional consultancy can deliver this combination. The report shows the developer the fixes and tells executive management whether it may go live.
01
Deep legal expertise
This falls to the team of Dr. Dominic Staiger, LL.M., Dr. iur., CIPP/E, Attorney at Law (New York) and Solicitor (UK). Under his responsibility it reviews the privacy notice and one data processing agreement with a service provider, usually the backend provider. We review further contracts on a time-and-materials basis. Data on servers outside Switzerland and the process for data breaches are also covered.
02
Our own software engineers
SIDD develops the Priverion Platform in its own development centre. Our engineers therefore know the building blocks of Lovable or Cursor projects such as React, Postgres and Stripe. They read RLS policies and login code themselves.
03
In-house AI development
We develop our own LLM systems and build with coding agents ourselves. So we know their shortcuts under time pressure: service key in the browser, policy set to true, missing validation.
What do we check?
We focus on the trust boundaries. There, data passes between browser, server and third-party services. This is where AI code fails most often.
Threat model light (STRIDE): One page names assets, roles, abuse cases and trust boundaries. From this we derive the test matrix: who may do what?
Manual code review plus SAST: With SAST, a tool such as Semgrep automatically searches the source code for errors. By hand we read login, authorisation, data access, uploads and payment.
Secrets and keys: gitleaks searches the Git history and the browser code for secret keys and passwords. We look above all for service keys that bypass every database rule. You replace any keys found the same day.
Authorisation and row-level security: We read every RLS policy, Firestore rule and edge function. In the Go-Live Review we test with test accounts, preferably on staging: anonymous, user A, user B, admin. We look for privilege escalation, IDOR and mass assignment. With IDOR, a changed number reveals other users' records. With mass assignment, a user can change their own role or credit.
Dependencies and SBOM: The SBOM lists all software packages built in. We check every package for known vulnerabilities and whether it exists at all. According to Spracklen et al., USENIX Security 2025 , up to one in five packages suggested by AI in 2025 was invented. Churilov, arXiv 2605.17062 still finds several percent with current models. Attackers register such names, which is called slopsquatting.
Backend and hosting configuration: The backend is the server with the database and login. For Supabase we check RLS on every table, storage policies, edge functions and auth settings. For Firebase we check Firestore and Storage rules plus App Check. For hosting we check environment variables with client prefixes, preview protection, security headers and CORS.
Dynamic test of the deployed app (Go-Live Review): We test the running app with DAST and by hand following the OWASP Web Security Testing Guide. We cover the OWASP Top 10:2025, such as injection, XSS, CSRF and rate limiting. Plus webhook signatures, paywall bypass and price manipulation.
AI features, where present: We check AI keys, spending limits and prompt injection against the OWASP Top 10 for LLM Applications 2025. For agents with tool access we recommend the AI security assessment.
Data protection launch checklist: In the Launch Check we derive the data map and the processor list from the code. In the Go-Live Review Dr. Staiger's team also reviews the privacy notice and the legal notice. It reviews in depth one data processing agreement (Art. 9 FADP or Art. 28 GDPR), usually with the backend provider. We review further contracts on a time-and-materials basis. Added to this is disclosure abroad under Art. 16 et seq. FADP or Art. 44 et seq. GDPR. This means servers outside Switzerland. Likewise the breach notification process (Art. 24 FADP) and the DPIA trigger (Art. 22 FADP). For AI features aimed at EU users, we check transparency under Art. 50 EU AI Act.
Remediation and re-test: You receive each fix as a prompt for your tool or as a code diff. Executive management receives a one-page go-live recommendation. On request we supply pull requests for critical and high findings, on a prior quote. The re-test confirms the remediation and is filed as evidence in the Priverion Platform.
Not included are a managed SOC, incident response standby and building a DevSecOps pipeline. There is no compliance guarantee. When your team outgrows the MVP, the next step is the Security Architecture Review.
Typical findings in vibe-coded apps
We find these gaps on every platform, ranked by frequency and damage:
1. Missing or incorrect authorisation: Tables have no RLS policy or one that lets everyone through. Serverless functions use the service key and check no permissions themselves.
2. Secrets in the browser code or in the Git history: such as the Supabase service key, Stripe or LLM keys.
3. Insecure backend and hosting defaults: public storage buckets and preview deployments. Google indexes production apps without a login.
4. IDOR and BOLA in generated CRUD code: access to other users' records by ID.
5. Missing input validation: This opens the door to XSS and injection. Uploads land unchecked in public buckets.
6. No rate limiting: Sign-ups, one-time codes and AI calls are possible without limit.
7. Invented or outdated dependencies: Packages do not exist or have not been maintained for years.
8. Admin, debug and test routes in production: Their error messages reveal too much detail.
9. Unverified webhook signatures and browser-only paywalls: The app does not verify the Stripe signature and checks payment only in the browser.
10. No logging, no backups, no environment separation: The log contains personal data or is missing entirely. Backups have never been test-restored. Often an AI agent has access to production.
Usually the data processing agreement with Supabase, Vercel or OpenAI is missing as well. Often a privacy notice tailored to the app and a breach notification process are missing too.
Figures that justify the review
Three dated and verifiable figures from studies since 2025:
45 %
of AI-generated code samples chose the insecure variant. The test covered 80 tasks and more than 100 language models. Newer models did no better. Source: Veracode GenAI Code Security Report , 30.07.2025.
16'326
Supabase databases showed their user table to anyone holding the public key from the browser code. More than half contained personal data. Source: UpGuard , 25.09.2026. The remedy: RLS on every table.
91 %
of 200 deployed apps built with Claude Code and Lovable had at least one vulnerability. Two thirds of the 1'186 findings were critical or high. Source: arXiv preprint 2606.23130, version dated 14.09.2026.
Packages and prices
All prices are excl. VAT. We agree the fixed price after an initial scoping call. The entry prices apply to one app with one repository and one backend, the server with database and login.
Launch Check
Agreed fixed price from CHF 3'900 1 app · report in 5 working days
For one app with up to about 10'000 lines of AI code. Suitable before the first external user, for internal tools without sensitive personal data and for accepting an agency handover.
Login, sessions and all access rules such as RLS policies
Secrets such as keys in the browser code and Git history, storage permissions, edge functions and Stripe webhooks
Dependencies, including packages made up by the AI
A01 to A03 of the OWASP Top 10:2025, for AI features also prompt injection
Data protection quick check: which personal data, stored where, which service providers
Report with fix prompts, a 30-minute debrief and one re-check of the critical and high findings within 30 days
Agreed fixed price from CHF 6'900 recommended · report in 10 working days
For apps with personal data or payments, in corporate use or before client acceptance. Everything in the Launch Check, plus logged-in tests and the infrastructure. Dr. Staiger's team assesses the complete data protection checklist. The entry price covers up to roughly 25'000 lines of AI code and 25 endpoints or tables. We clarify two backends, a mobile client or a larger scope during scoping.
Authorisation matrix with one test account per role against staging or the live API. We look for IDOR, meaning other people's data reached by changing a number. Plus tenant isolation and role escalation.
Payments with Stripe webhook signatures and price manipulation, file upload, email and OTP flows
Infrastructure: hosting settings, backups with a restore test, logging, separate environments and an incident contact
45-minute threat model session with your team: who could attack what?
Review of one data processing agreement, further ones on a time-and-materials basis. Disclosure abroad to servers outside Switzerland, privacy notice, legal notice and breach notification process. Legal assessment by Dr. Staiger's team.
Fixes as code or prompt, evidence pack in the Priverion Platform, one re-test of the critical and high findings within 60 days
Which package suits your app is something we settle in the initial consultation in 30 minutes.
How the review runs in five or ten working days
The days apply to the Launch Check. In the Go-Live Review the report follows after ten working days. You need no installation, no developer of your own and only one point of contact.
Day 0: scoping in 30 minutes
You show us the app, its data and user groups. We agree the fixed price after an initial scoping call. You give read access to the repository, the URL of the live app and one test account per role. For the backend, a temporary membership with minimal rights is enough.
Day 1: threat model light and scans
We record the data worth protecting, the roles and the trust boundaries. There data passes into other hands, for example to an AI service. From this follows the test matrix: which role may do what? Three scans run in parallel: SAST for code errors, a Git secret scan and an SBOM as package list.
Days 2–3: manual review and tests
We read the code for login, data access, payment and AI by hand. We check every RLS policy individually. In the Go-Live Review we test the role matrix with the test accounts. This runs against staging or by agreement against the running app. We add a dynamic test following the OWASP WSTG.
Days 3–4: data protection check
From the code we derive a data map and a list of service providers. In the Launch Check the data protection quick check ends here. In the Go-Live Review Dr. Staiger's team reviews the complete data protection checklist. This includes the review of one data processing agreement, further ones on a time-and-materials basis.
Day 5: report and debrief
Every finding gets a fix as a code change or as a prompt for your tool. Executive management receives a one-page go-live recommendation. In the debrief we settle the order and who is responsible.
Within 30 to 60 days: re-test and evidence
We re-check the remediated critical and high findings and repeat the scans. We file the result as an evidence pack in the Priverion Platform . On request we deliver an RLS test suite for your CI. That way the next table without a policy gets noticed.
Why SIDD
What the three disciplines bring to your app:
We build with AI ourselves
We work with coding agents every day. For example, a Supabase table created via migration starts without an RLS policy. Then nothing controls who sees which row. We check such points first.
Access rights checked by hand
We check by hand whether each policy fits your roles. In the Go-Live Review we test every role with test accounts.
Go-live decision with a legal basis
Every finding names the FADP or GDPR obligation it touches. That way executive management knows whether it may go live.
Fixes you can paste in
Developers apply the code diff line by line. Without a developer, a prompt for Lovable or Cursor is enough.
Confidential, reviewed in Switzerland
The analysis runs on our infrastructure in Switzerland, with no copy of your code at third parties. We use AI tools only with your consent and with no training use. For the legal assessment under Dr. Staiger's responsibility, lawyers' professional secrecy (Art. 321 Swiss Criminal Code) also applies.
Audit-ready evidence
Findings, remediation status and re-test sit audit-ready in the Priverion Platform. You show this evidence to customers, investors and the ISO/IEC 27001 auditor. If we write fixes ourselves, the report says so. If a customer requires an independent review, we separate the mandates.
Scanner, review and penetration test compared
A scanner reports known patterns. A penetration test attacks a mature system from the outside. The review sits in between and looks for the typical errors of AI code.
Automated scanner
Vibe-Coding Security Review
Classic penetration test
Scope: code or running app, known patterns
Scope: code, backend configuration and running app
Scope: running app, network, API
RLS logic: finds missing RLS, not wrong rules
RLS logic: reads every policy, tests it per role
RLS logic: tests from the outside only
Secrets: current code, history in part
Secrets: entire Git history plus browser code
Secrets: browser code, Git history usually not
Data protection: contracts, disclosure abroad, breach notification unchecked
Data protection: launch checklist by lawyers, review of one data processing agreement
Data protection: not part of the test
Fixes: general hints
Fixes: code diff or prompt per finding, re-test included
Fixes: remediation recommendation, re-test by arrangement
Duration: minutes
Duration: 5 to 10 working days
Duration: 3–10 tester-days over 2–4 weeks, entry package 5 days
Price: free or platform credits
Price: agreed fixed price from CHF 3'900
Price: entry package from CHF 1'490, web app projects CHF 12'000–25'000
Why we work with LexCommand, our own Swiss legal AI
LexCommand is our in-house, citation-backed legal AI for the law of Switzerland, Germany, Austria and the EU. Developed and run sovereignly in Switzerland by Priverion GmbH, the company behind SIDD. We do not just preach data sovereignty and provability, we built them into our own tool, alongside the Priverion Platform.
01
Sovereign in Switzerland
The AI runs self-hosted on Swiss infrastructure, with no external cloud LLMs. As an independent Swiss company with no foreign parent, we process your documents in an environment we control.
02
No citation, no claim
Every legal statement traces back to a retrievable primary source, or it does not appear at all. That makes our recommendations auditable and verifiable, instead of merely sounding plausible.
03
From effort to judgement
LexCommand takes over searching, cross-checking and sourcing. That shortens turnaround times and frees our senior advisors for judgement and client dialogue, with no loss of diligence.
04
Three disciplines, one picture
We look at data protection, information security and AI security on a shared source base with a framework crosswalk. So you see overlapping obligations in one consolidated picture, instead of three isolated analyses.
Specifically for this review: LexCommand backs every finding with the obligation under the FADP, GDPR or EU AI Act. It drafts the processor list and breach notification process with sources.
Temporally deterministic (as of today or any reference date), with jurisdiction isolation (CH/DE/AT/EU) and a citation verifier at the end of every answer.
Frequently asked questions
What does the Security Review for Vibe-Coded Projects cost?
Launch Check: Agreed fixed price from CHF 3'900, report in five working days. Go-Live Review: Agreed fixed price from CHF 6'900, report in ten working days. Due Diligence and Portfolio: Agreed fixed price from CHF 10'500, all prices excl. VAT. We agree the fixed price after an initial scoping call.
Do you need the source code, and which platforms do you review?
We need read access to the repository, the live URL and one test account per role. For the backend, a temporary membership or an export of schema, policies and rules is enough. We review apps from Lovable, Bolt, Replit, v0, Base44, Cursor, Windsurf, Claude Code and GitHub Copilot. We also cover backends like Supabase, Lovable Cloud or Firebase, hosts like Vercel or Netlify and other stacks by agreement.
We have no developer. Who fixes the findings?
Every finding comes with a fix for your tool: a prompt or a code diff, line by line. On request we fix critical findings via pull request, with write access granted specifically and effort quoted in advance. A re-test then confirms and documents the remediation.
How does this differ from a penetration test and the AI security assessment?
A classic penetration test attacks the app only from the outside, from CHF 1'490 with a report in five days. Projects of three to ten tester-days over two to four weeks pay off with enterprise customers and your own infrastructure. The Launch Check costs more because it also reviews the code, Git history, every RLS policy, data protection and any chatbot. AI Security tests the AI system itself from CHF 8'000 per application and pays off for agents in production.
Lovable offers a scanner and a pentest. Isn't that enough?
Both are a good start and should run after every major release. The scanner does not see whether a policy fits your roles and data flows. No platform tool checks contracts with processors, the privacy notice or the breach notification process. The review builds on the scan and gives enterprise customers and investors a second opinion from a named reviewer.
Do you test on our production system? Does that put operations at risk?
We prefer to test on a test environment, and in production only with our own test accounts and test data. We send no destructive payloads and follow rules of engagement agreed in writing. We check payments in Stripe test mode and delete our test data afterwards. The Launch Check does not attack the app anyway and only reads code, configuration and secrets such as passwords.
Are we even allowed to go live with customer data?
Yes, once data security, a privacy notice, processor contracts and a breach notification process are in place (Art. 7–9, 19 and 24 FADP, Art. 1–6 Data Protection Ordinance). Anyone who wilfully disregards the Ordinance's minimum requirements risks, on complaint, a personal fine of up to CHF 250'000 (Art. 61 let. c FADP). The launch checklist lists the open points, including the processor list and the review of one data processing agreement, further contracts on a time-and-materials basis. After that, the external data protection advisor mandate or the FADP compliance project can help.
What happens if findings are critical?
We report critical findings immediately with a fix, before the report is finished. You can then fix open tables or a master key in the browser code the same day. If personal data was actually accessible, Dr. Staiger's team examines the notification duty. The notification would go to the FDPIC (Art. 24 FADP) or an EU supervisory authority (Art. 33 GDPR, 72 hours).
What happens after launch?
Every AI release can add tables without a policy, new endpoints and new dependencies. After major changes, we recommend a new Launch Check. Once the app grows into an enterprise product, the Security Architecture Reviewfollows: agreed fixed price from CHF 6'900. It delivers a target architecture and a threat model: who could attack what. For SaaS providers , the contracts with processors are added.
This page does not replace legal advice in individual cases.
Know what is open before go-live
We agree the fixed price after an initial scoping call. You receive your report from five working days. Then you know every open gap and have evidence for customers and investors.
