HomeHow It WorksPricingGet Your Scan
Sample Report — For Illustration Only

Security Audit — myapp.io

This is a sample of what your VibeClear report looks like. Your real report will be personalized to your app's specific vulnerabilities, tech stack, and urgency — not a fictional example.

Target
https://myapp.io
Scan Type
Human Review — Pro
Stack
Lovable + Supabase + Vercel
Scanned
May 1, 2026 — 10:42 AM
Reviewed By
Maya J. — VibeClear
30
/100

High Risk — Immediate Action Required

We found 3 critical and 4 high-severity vulnerabilities putting your users' data at direct risk. The most urgent — exposed API keys in your JavaScript — means any visitor can read your entire database right now. Fix this today.

3Critical
4High
2Medium
6Low / Pass
Critical Findings
3 issues — fix today
Critical
Supabase API Keys Exposed in Public JavaScript
Found in: /static/js/main.chunk.js · Line 4,821
What This Means — In Plain English

Your Supabase service role key is embedded in your compiled JavaScript file. This file is publicly accessible — anyone who visits your app can find it by opening browser developer tools. With this key, an attacker can bypass all database security and read, write, or delete every record. No login required.

Evidence Found
// Found in main.chunk.js — publicly accessible to any visitor const supabaseUrl = "https://xxxxxxxxxxxx.supabase.co" const supabaseKey = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3Mi..." // ⚠ This is a service_role key — full database access, bypasses all RLS
How to Fix It — Step by Step
  1. Immediately rotate your Supabase service role key in your dashboard under Settings → API → Rotate keys.
  2. Move all operations that use the service role key into a backend function (Supabase Edge Function or a server-side API route). This key should never touch the browser.
  3. On the client, only use the anon key — and only after enabling Row Level Security on all tables.
  4. Check your .env file is listed in .gitignore and was never committed to your repository.
Critical
Row Level Security Disabled — All User Tables Exposed
Affects: users · orders · documents · messages tables
What This Means — In Plain English

Even if you fix the API key issue, there's a second problem: your database tables have no access restrictions. Any logged-in user can query records belonging to other users. User A can see User B's orders, messages, and private documents just by modifying a request in their browser.

Evidence Found
-- Verified: unauthenticated request returned all user records GET /rest/v1/orders?select=* HTTP/1.1 -- Response: 847 rows returned, no authentication required {"id":1,"user_id":"abc","amount":249.99,"card_last4":"4242"} {"id":2,"user_id":"xyz","amount":89.00,"email":"other@user.com"}
How to Fix It — Step by Step
  1. In Supabase Dashboard → Table Editor, click each affected table and enable Row Level Security.
  2. Add a policy for each table: USING (auth.uid() = user_id) — ensures users only see their own rows.
  3. Test by logging in as a regular user and trying to fetch another user's records. You should get zero results.
Critical
Admin Access Controlled Only in the Browser
Found in: /src/components/AdminPanel.jsx · /src/pages/Dashboard.jsx
What This Means — In Plain English

Your admin panel is "protected" by a check that happens entirely in the browser: if the user's role says "admin", show the admin area. Any user can open DevTools, change that value, and instantly gain admin access. The data is also being fetched regardless of the role check.

Evidence Found
// AdminPanel.jsx — the "protection" is visual only {user.role === 'admin' && ( <AdminDashboard users={allUsers} /> // allUsers fetched regardless )}
How to Fix It — Step by Step
  1. Move all admin data fetching to a Supabase RPC or Edge Function that verifies the user's role from their auth token server-side before returning any data.
  2. Add a Supabase RLS policy: USING (auth.jwt() ->> 'role' = 'admin')
  3. Never trust a role value that comes from the client. Always verify from the server-side auth token.
High Severity Findings
4 issues — fix this week
High
No Content Security Policy — Browser Injection Possible
All pages — no CSP header present
What This Means — In Plain English

Without a Content Security Policy, if an attacker ever finds any way to inject code into your pages, they can run any script they want — stealing session cookies, redirecting users to fake login pages, or silently logging everything users type. A CSP is a critical last line of defense.

How to Fix It
  1. Add a Content-Security-Policy header in your Vercel headers config: default-src 'self'; script-src 'self';
  2. Use Report-Only mode first to spot any violations before enforcing.
High
No Rate Limiting on Login & Password Reset
/api/auth/login · /api/auth/reset-password
What This Means — In Plain English

Your login and password reset pages accept unlimited requests with no slowdown. An attacker can try thousands of password combinations automatically, or abuse your password reset to flood users with emails.

How to Fix It
  1. Enable Supabase's built-in rate limiting under Auth → Settings → Rate Limiting.
  2. Set login lockout: block an account for 30 seconds after 5 failed attempts.
  3. Add CAPTCHA to login and password reset using Supabase's built-in CAPTCHA protection.
Additional High FindingsSeverityEffort to Fix
CORS policy allows all origins (*) — any website can make requests to your APIHighLow — 1 config change
HSTS header missing — users can be silently downgraded to HTTPHighLow — 1 header to add
Checks Passed
6 passing
SSL certificate valid and current
No open directory listings detected
TLS 1.2+ enforced (1.0/1.1 disabled)
No publicly accessible .env files
Passwords hashed (bcrypt detected)
No known vulnerable npm packages

Ready to scan your actual app?

This sample shows what a Human Review report looks like. Your real report is specific to your URL, your stack, and your actual vulnerabilities — not a fictional example.

Get My Security Report   View Pricing