A User Just Told You Their Data Is Visible to Other Users. What To Do in the Next 4 Hours.

Hour 0–1: Assess and Contain

First question: is data still actively exposed? Check whether user records can be queried without user filtering, and whether a logged-in user can fetch another user's data by changing an ID.

If yes, take the affected feature offline immediately. Preserve evidence: screenshots, API responses, and the user's report.

Hour 1–2: Find the Root Cause

Missing Row Level Security.

The AI created tables and queries but did not add RLS policies. Any authenticated user can query any row.

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';

Missing authorization check.

The endpoint checks whether the user is logged in, but not whether the requested data belongs to that user.

Hour 2–3: Fix and Verify

Fix the specific vulnerability only. Then verify with test accounts: User A should not be able to access User B's data. Bring the feature back online only after verification.

Hour 3–4: Notify Affected Users

Notification should include what data was potentially visible, when exposure existed, what you fixed, and what users should do. Be honest, specific, and direct.

FAQ

Do I need a lawyer?

If you have EU users, consult a GDPR-aware lawyer within 24 hours. If you have US users, understand your state's breach notification laws.

Will this kill my startup?

An honest, fast response rarely kills a startup. Coverups, slow response, and repeat incidents do.

How do I make sure this doesn't happen again?

Enable RLS on every user-data table and add ownership checks to every user-specific API endpoint.