What you actually receive at the end of a review.

What we found

The transactions table had Row-Level Security enabled, but its SELECT and UPDATE policies only checked that the caller was authenticated, not that the row belonged to them. The UI filtered correctly, which hid the problem; calling the REST API directly returned every customer's rows.

Evidence — request made with test account B (redacted)

curl "https://[project].supabase.co/rest/v1/transactions?select=*" \
  -H "apikey: [anon key]" \
  -H "Authorization: Bearer [account B session]"

# 200 OK — 1,248 rows, including rows owned by account A
# and by 37 other organizations

Business impact

Every customer's financial data was readable, and editable, by any user with an account, including a free trial account.

Recommendation

Restrict both policies to rows owned by the caller's organization, and add a test that fails if another account can read a row.

create policy "org members read own transactions"
on transactions for select
using (org_id in (
  select org_id from memberships where user_id = auth.uid()
));

What we found

The invoice export link passed the user's session token (JWT) as a URL parameter. Full URLs, token included, were stored in the hosting provider's request logs and in browser history.

Evidence — log line from staging (redacted)

GET /export?invoice=[id]&token=eyJhbGciOi…[redacted] 200

Business impact

Anyone with access to the logs, or to a shared computer's history, could reuse a valid session and act as that user until the token expired.

Recommendation

Send the token in the Authorization header (or rely on the httpOnly session cookie), shorten token lifetime, and purge existing logs that contain tokens.

What we found

Signed contracts uploaded by customers were stored in a public bucket, under predictable paths based on the invoice number.

Evidence — unauthenticated request (redacted)

curl -I "https://[project].supabase.co/storage/v1/object/public/contracts/INV-2026-0142.pdf"

# HTTP/2 200 — no session, no token

Business impact

Confidential customer contracts were accessible to anyone who guessed or found a URL.

Recommendation

Make the bucket private, serve files through short-lived signed URLs checked against the user's organization, and rename existing files so old URLs stop working.

What we found

The login and password reset endpoints accepted 50 consecutive attempts from the same IP without delay or block. No account was compromised during the test.

Observation during testing

50 failed logins in 40 seconds from one IP → no rate limit, no lockout, no alert

Business impact

Makes password guessing and reset-email flooding practical.

Recommendation

Add rate limiting per IP and per account on both endpoints, with a short progressive delay.

What we found

The app sends no Content-Security-Policy header. No injection point was found during the review.

Observation

Response headers: no content-security-policy

Business impact

Not a vulnerability by itself, but it would limit the damage of a future script injection.

Recommendation

Add a CSP, starting in report-only mode to avoid breaking the app.