Get your Lovable app reviewed before Supabase, RLS or secrets become a risk
Lovable builds your app in hours, and it works. Whether it is also production ready is decided at Supabase, RLS and secrets. I review exactly those points as a Lovable security audit, rank what is genuinely critical, and then keep repo, CVEs and infrastructure under ongoing technical oversight.
- Baseline from 790 €
- Supabase, RLS and secrets in focus
- Repo + CVE + infrastructure
- German point of contact
Direct point of contact
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director
I review code, security and infrastructure and surface what is technically risky before launch, customer use or due diligence.
I have delivered production software, infrastructure and cloud systems for clients worldwide, including Europe, the UAE, Asia, Australia and the Americas: from automated multi-location platforms and cloud migrations to remote access systems for industrial plants.
For questions like:
- Is this release production-ready?
- Which CVEs are really critical?
- Are auth, data access and tenant isolation clean?
Lovable apps work fast, but production has its own rules
Lovable gets you to an app that runs in a demo in record time. That same speed skips decisions that only become a problem in front of real users. These are the gaps we see most often in Lovable apps:
- Login exists, but access to the data itself is not protected
- Supabase RLS disabled or set with overly permissive policies
- Keys in the frontend bundle that every visitor can read
- Server-side validation missing, the client is treated as trusted
- Edge Functions without auth checks or input validation
- Deployment without security headers, CORS rules and rate limits
- No monitoring, no logging and no backup plan
- Dependencies with known CVEs that nobody updates anymore
Supabase and RLS: login is not access protection
Lovable wires Supabase in as the backend, and login works straight away. That does not mean the data is protected. Authentication only answers who someone is. Authorisation answers what that person may see and change. In Supabase, that second layer lives in the Row Level Security policies, and during fast building they often go unset or incomplete.
If RLS is disabled, a logged-in user can query more through the openly reachable API than the interface shows. The table then returns rows that actually belong to other tenants. Policies that are enabled but too broad are a risk too: a rule that only checks whether someone is logged in does not separate one tenant from another.
We check whether RLS is enabled on all relevant tables, whether the per-user or per-tenant policies actually isolate, and whether any tables are accidentally reachable in the open. We rank every finding by severity so you can see what is genuinely production critical.
Secret handling: anon key, service_role key and third-party keys
Supabase has two keys with very different reach. The anon key belongs in the frontend on purpose and is only safe in combination with active RLS policies. The service_role key bypasses RLS entirely and must never reach the client. That exact mix-up happens during fast building, and then a key with full access sits in the bundle that every visitor can open.
On top of that come third-party keys: OpenAI keys for AI features, Stripe secrets for payments, tokens for email or storage. If these end up in the client or in the repository, someone can read them and use them on your bill. With payment and AI APIs that quickly turns into direct financial damage.
We look for keys in the frontend bundle, in the Git history and in the configuration, check whether the service_role key stays safely server-side, and show which calls should run through an Edge Function instead of directly from the browser.
Edge Functions and server-side validation
As soon as a Lovable app does more than display data, Supabase Edge Functions come into play: for payments, AI calls or actions that must not happen in the browser. But an Edge Function only protects you if it checks for itself who is calling and with what data. Otherwise it just moves the problem from the client to the server.
Typically the function does not re-check the caller's identity, passes input straight to the database or a third party without validation, or assumes only its own interface calls it. Anyone who knows the endpoint can call it directly, though. Server-side validation means the function distrusts every input, no matter where the call comes from.
We look at whether Edge Functions check auth correctly, validate input and use the service_role key only where needed, and whether critical actions are really decided server-side instead of in the browser.
Deployment: headers, CORS, rate limits, monitoring and backups
A working app is not yet an operable app. What sits between deploy and real operation is often missing entirely in Lovable projects. We review that operations layer with:
- Security headers such as Content-Security-Policy and HSTS set
- CORS rules kept tight instead of opened to all origins
- Rate limits on login, API and Edge Function endpoints
- Monitoring and logging so errors and attacks become visible
- Backups of the Supabase database with a tested recovery path
- Separation of environments so test and live data do not mix
What Lovable scans do and where Veriploy adds value
Lovable ships its own security checks, and those are a good start. A scanner finds plenty of findings: it flags a missing policy, an exposed key or an outdated dependency. What a scanner does not do is rank them, the way a manual Lovable code review does. It does not tell you which finding genuinely endangers you in front of real users and which one can wait.
That is exactly where Veriploy comes in. We take the findings, rank them by production criticality and translate them into a clear order: what must be fixed now, what matters before the next release and what stays uncritical. This human prioritisation does not replace the Lovable scan, it makes it usable.
And because Lovable apps change with every prompt, it does not stop at a one-off look. You get the app reviewed once (Baseline) and then keep repo, CVEs and infrastructure under ongoing technical oversight with Oversight, Guard or Launch. That keeps the risk dashboard current instead of going stale with the next feature.
How the Lovable review works
- 01
Clarify the Lovable context
First we clarify how the app was built: Lovable project, Supabase project, auth, tables, Edge Functions, storage, payments, user roles and the planned launch.
- 02
Map repo, Supabase and deployment
I review how the frontend, Supabase, database rules, Edge Functions and deployment work together. Particularly important: which logic runs in the client, which runs server-side, and where the secrets live.
- 03
Review RLS, auth and data access
With Lovable apps the biggest risk often is not in the UI code, but in wrong or missing Supabase RLS policies, storage rules, service_role usage or overly broad database access.
- 04
Findings and priorities
The result is concrete findings such as: RLS missing, storage bucket public, auth checks login but not the role, service_role key used incorrectly, API endpoint without validation.
- 05
Launch or subscription recommendation
After that it is clear whether a Baseline is enough, or whether the project should be supported on an ongoing basis with Guard or Launch.
Many projects start with a Baseline review. If the product keeps being developed with AI afterwards, Veriploy can support it on an ongoing basis.
What I need for the review
- read-only access to the repository
- a short description of stack, tool and goal
- details on hosting and deployment
- database and auth context
- notes on sensitive data or user roles
- open questions or specific concerns
What the review delivers
- an understandable risk rating
- top risks at a glance
- prioritised findings
- concrete recommended actions
- guidance: fix now, fix before launch, plan for later
- an optional recommendation for Oversight, Guard or Launch
What a finding looks like
Supabase RLS for the invoices table is incomplete, users could see other tenants' invoices. Recommendation: enforce a policy per user_id.
Lovable scan or ongoing oversight by Veriploy?
| Lovable scan | Veriploy ongoing | |
|---|---|---|
| Result | List of findings with no order | Findings ranked by production criticality |
| RLS and secrets | Detected automatically where patterns match | Reviewed manually for real tenant isolation |
| CVEs and dependencies | State on the scan run | Ongoing monitoring with heads-ups |
| Infrastructure and operations | Only partly in view | Headers, CORS, rate limits, backups reviewed too |
| Before a release | Another scan needed | Human judgement included in the plan |
Frequently asked questions
Is this a penetration test?
No. Veriploy is an ongoing technical review of repo, security, CVEs and infrastructure, not a classic pentest. As a Lovable security audit we look especially at Supabase, RLS and secrets. A pentest can complement it when you want to simulate targeted attacks.
Do you also do the fixes?
Not within the plan. We review, prioritise and explain what needs to be done, for example how an RLS policy should look or how a key ends up safely server-side. Implementation runs separately through Wevelsiep Advisory or WZ-IT, or your own team. That keeps the review independent from the implementation.
Do you need repo access?
Yes, read-only by default. Read access to the repository and a look at the Supabase configuration are enough for the review. We do not need write access, because we do not commit the fixes ourselves.
Does this replace the Lovable security scan?
No, it complements it. The Lovable scan finds findings, which is a good start. I rank which of them are production critical in front of real users and then keep repo, CVEs and infrastructure under ongoing oversight. Scanner and human prioritisation work together.
What does it cost?
The entry point is fixed: Baseline 790 € as a one-off review. Ongoing oversight starts at 990 € per month (Oversight), then Guard at 1.950 € and Launch at 3.900 € per month. All prices net plus VAT. Ongoing packages start with a 3-month minimum term, then cancelable monthly, unless agreed otherwise.
- Get your AI app reviewed, with ongoing technical oversight instead of a one-off gut check
- Get your Base44 app reviewed before data access, auth or integrations become a risk
- Get your Bolt app reviewed before architecture and auth become a problem
- Get your Supabase RLS reviewed before user data leaks through the wrong policies
- Vibe coding security audit, plus ongoing control as the code keeps growing
Do you recognize these risks in your own app?
The AI-app risk self-check assesses product status, stack, auth, data access, infrastructure, CVEs and your technical knowledge, and shows whether a review makes sense.
Get your Lovable app reviewed and keep it monitored afterwards.
Start with the Baseline, then ongoing oversight in the plan that fits.
Check repo fit
Briefly describe the project.
Direct contact with me, no anonymous ticket system. I get back to you with a first assessment and the right entry point.
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director