How to scan your app for security issues

Every project has a Security view: one scan across five areas, findings grouped by severity, and a route from a finding to a fix that runs through chat instead of a ticket.

Two depths

Depth	Runs	Scanners	Triggered by
Basic	Background, seconds	Code, Sensitive data	Every publish, automatically
Deep	Full pass, including your database	Code, Dependencies, Row-level security, Database, Sensitive data	You — from the Security view, or by asking in chat

Deep reaches into your linked Supabase project to check policies and advisor findings. With no Supabase project linked, the RLS and Database scanners are skipped with an info note and the other three still run.

The five scanners

• Row-level security — tables with RLS off, and policies permissive enough to be no policy at all.
• Database security — Supabase advisor findings: SECURITY DEFINER misuse, exposed auth tables.
• Code security review — hardcoded secrets, dynamic eval, dangerous HTML, client env leaks. On a mobile project it automatically applies the mobile rule set: insecure AsyncStorage, unvalidated deep links, cleartext traffic.
• Dependency audit — known CVEs in package.json, resolved in the build environment with an OSV fallback.
• Sensitive data — personal data written to logs, to storage, or to unencrypted fields.

The status word that matters

The header carries one rollup: Up-to-date, Outdated, Scanning, Failed or Never run. Watch Outdated. Findings describe a snapshot of your code; edit the files a finding points at and it does not silently update — the status flips and you re-scan. A clean Security view from three days and forty edits ago is not evidence about today.

Severities and the publish gate

• Error — exploitable as written. This is what the publish gate blocks on.
• Warning — a real weakness needing judgement, usually a policy or a dependency where the right fix depends on your app.
• Info — worth knowing: a note, a skipped scanner, a pattern that is fine here but would not be everywhere.

Fixing a finding

Every finding has a fix action, and it does not patch your code behind your back. It composes a prompt naming the finding, the file and the line with the suggested remediation, and hands it to chat. You read it, send it, and review the diff like any other change. Fix all does the same for every open finding — which also means a large diff, so it is worth taking errors one at a time.

Do this before launch

1. Run a deep scan and clear every Error.
2. Re-scan after the fixes. The status word tells you whether the report still applies.
3. Check RLS specifically if your app has user data — a query that returns rows it should not is the single most common flaw in a generated app, and it is invisible from the UI while you are the only user.
4. Rotate anything that ever appeared in a screenshot or a shared log. A leaked key is rotated at the source first — Stripe, RevenueCat, Supabase — then updated in the connector drawer.