Know what the audit does.

Start with a workspace.

Create an account, then create a workspace and project in the dashboard. Add the app URL, source or Supabase input you are authorized to audit. A project keeps related inputs and scan history together.

The Free plan shows score, coverage and severity counts. A Launch Audit credit or active Builder subscription opens the complete findings, proof, PDF and fix prompts.

Choose your audit inputs.

Live URL: add the app’s exact origin. Use DNS TXT or a meta tag to prove control before any scan. Verification lasts 30 days. Other origins require separate verification and explicit scope.

Source: connect a public or private GitHub repository through the GitHub App’s read-only contents permission, or upload a ZIP. ZIP uploads require an ownership attestation. Repository code is inspected without running its scripts.

Supabase: provide a read-only audit connection or paste the SQL metadata export. Never provide the service_role key. The setup panel supplies the catalogue export query. Metadata checks examine RLS, policy expressions, storage buckets and SECURITY DEFINER functions.

Link inputs from the same project for a combined URL audit. Missing source, backend metadata or account scopes will remain visible as untested coverage.

Record consent before scanning.

Only audit an app you own or are authorized to test. The service records the actor, time, IP and accepted scope for each scan. Verification and consent are rechecked before the worker makes requests.

URL scans are blocked when domain verification lapses. A ZIP or Supabase input needs an explicit ownership attestation. GitHub access must come from an authorized installation grant.

Scans are read-only by default, bounded and rate-limited. There are no destructive payloads. Cancel a queued or running scan from Reports. Cancellation is checked during execution.

Prepare two test accounts.

Supply dedicated User A and User B sessions and a supported identity endpoint. The tester confirms that the sessions identify different accounts. Use synthetic objects with clear ownership; do not use real customer sessions.

Automatic capture is conservative: it recognizes explicit id and user_id fields on bounded same-origin reads. Use explicit replay scopes for other shapes and linked Supabase reads. Ambiguous ownership, mixed-owner data and unsupported responses remain untested.

User B and logged-out reads may run on a verified production target, but only on the designated test-owned objects. Update/delete replays need staging on both app and backend, exact disposable row scopes and explicit opt-in. Generic writes are skipped. There is no rollback promise for arbitrary applications.

Read the score with coverage.

The 0–100 readiness score prioritizes findings. Critical, high, medium and low findings deduct 35, 18, 7 and 2 points; suspected findings count half. Related duplicates are grouped. Incomplete coverage limits the maximum score.

Proven means a deterministic check produced evidence. Suspected means a signal needs confirmation. Untested means the check could not safely run or lacked input. An untested check is never a pass.

A clean scan is not a guarantee. Read the checks that ran and their scope, review the repair, and repeat the audit after changing the app.

Take the finding back.

Open a full report, choose Lovable, Bolt, Cursor or Claude Code, and generate the fix prompt. The explanation service sees bounded, redacted finding data and is used only for wording, not detection.

Review and apply the proposed repair, then scan again. Download the PDF before the evidence expires after 30 days. Keep exports and test sessions current for the next audit.