Illustrative sample · synthetic data

See what a finding says.

An example of the full report. These results describe a made-up app.

OkToShipLaunch audit · example-app.testIllustrative

Readiness64/100

Review before launch.

Two proven findings. One check needs more input.

Check	Result
Logged-out table readHigh · Proven	Fail
User B read A’s test rowHigh · Proven	Fail
Bundle secret scanCompleted	No findings
Write replayNo staging scope supplied	Untested

Redacted evidence

GET /rest/v1/profiles → 200
3 rows returned · emails masked
a***@example.test

Illustrative report, not an audit of a real customer. No secrets or personal data.

Coverage

Scope stays visible.

Bundle secret check completed
Logged-out profiles read completed
Two-account read replay completed

Untested

Write replay skipped. No staging environment or disposable write scope supplied.

The two high-severity findings deduct 18 points each. The score is 64/100, within the incomplete-coverage ceiling.

GET/findings200

Two proven findings.

Each finding shows the request, the redacted response and the fix.

High · ProvenFail

Profiles are readable without signing in.

A logged-out visitor received three synthetic profile rows. This example treats profiles as private data.

REQUEST        GET /rest/v1/profiles?select=id,email&limit=3
SESSION        logged out · public anon key
RESPONSE       HTTP 200 · 3 rows
EMAIL SAMPLE   a***@example.test
SECRET VALUES  omitted

Recommended fix

Review every SELECT policy that applies to anon. Allow private profile reads only when the authenticated user owns the row.

High · ProvenFail

User B can read A’s profile.

The same read returned A’s dedicated test row while using B’s session. The response matched the designated synthetic object.

REQUEST                    GET /rest/v1/profiles?id=eq.test-profile-a
OWNER                      dedicated User A
REPLAY SESSION             dedicated User B
RESPONSE                   HTTP 200 · test-profile-a returned
PRODUCTION CUSTOMER DATA   none

Recommended fix

Enforce ownership on the server or database policy, then test A, B and logged-out access separately.

Take it back to your tool

Start with a specific repair.

This sample prompt is editable context. A real audit generates it from your redacted finding.

In Lovable, repair the authorization of the profiles table. This is an illustrative audit, not a real customer finding.

Evidence: a logged-out GET /rest/v1/profiles returned 3 rows. Emails were masked. User B also read the synthetic row owned by User A.

Expected behavior: profiles are private; an authenticated user can read only their own profile. Inspect every applicable SELECT policy and API route. Remove unintended anon access. Use the application's actual owner column and auth.uid() for row ownership. Do not use a service_role key in client code. Do not assume an owner-column name or apply a migration until the schema is reviewed.

Add tests for User A reading their own row, User B being denied A's row, and a logged-out visitor being denied. Preserve any deliberately public data in a separate, reviewed scope. Show the migration and tests for review, then rerun the audit on dedicated test data.

Now check your own app.

A clean scan is not a guarantee. Verify ownership and review the checks that run.

Create a workspace See a sample report