ESENPT

Sample report with fictional data.

← Back

Review report

Project
corredores-crm
Tested commit
a3f9c21
Date
2026-10-15
Environment
Rebuilt from the repository · Desktop Chromium · fictional data

Summary

Your app works for the main things: creating and editing clients is saved correctly. We found one serious problem: Pedro (User B) can see and edit Ana's (User A) clients. Fix that first.

1 · Failed1 · Suspected3 · Passed1 · Not verified

Flows and checks

  • Passed

    Sign up and sign in

    With email confirmation captured in the test environment.

  • Passed

    Create and edit a client

    The change is still there after reload and in a new session.

  • Failed

    User B with User A's clients

    Pedro sees and edits one of Ana's clients, also via the API.

  • Passed

    Signed-out visitor

    Can't access private routes or data.

  • Suspected

    Notes table without row protection

    Found in the code; not confirmed by running it.

  • Not verified

    Real card payment

    Out of scope: a simulated service was used.

Finding 1Failed

Pedro (User B) can see and edit Ana's (User A) clients

Severity:
High
Confidence:
High · executed

Impact

Any agent can see another agent's entire portfolio and change their sales stages.

Preconditions and role

Two signed-in agents. Ana has the client “Sol Realty”.

Steps to reproduce

  1. 1Sign in as Ana and create the client “Sol Realty”.
  2. 2Sign out and sign in as Pedro.
  3. 3Open “My clients”: “Sol Realty” appears.
  4. 4Change its stage to “closed” and reload: the change is saved on Ana's client.

Expected

Pedro only sees and edits his own clients; the API rejects the change.

Observed

Pedro's list includes Ana's clients and the API accepts the change (204).

Evidence

GET /rest/v1/clients · Pedro
200 OK · 2 rows, 1 of Ana's
[{ "id": "c_01…", "name": "Sol Realty", "user_id": "<A>" }, …]
PATCH /rest/v1/clients?id=eq.c_01… · Pedro
204 No Content · stage: "negotiation" → "closed"
SELECT stage FROM clients WHERE id = 'c_01…'
"closed"

Technical location

supabase/migrations/20260901_clients.sql · policy “Authenticated can read clients”

Cause hypothesis

The table's policy lets any signed-in user read and write (condition true), without comparing user_id to the current user. This is a hypothesis, not a conclusion.

Prompt to fix it

Paste it into Claude, Cursor, Lovable, Bolt or another tool.

In my app, agents can see and edit other agents' clients.
Fix access to the "clients" table so each user can only read and modify their own records (user_id = auth.uid()), both from the UI and when calling the API directly.
- Create a new migration; don't edit previous migrations.
- If there's an admin role that must see everything, keep that access with a separate policy.
- Don't change other tables or other features of the app.
- When you're done, explain what you changed so I can press "Test again" in UserB.

Was this finding useful?

Uses the included re-run. Nothing runs in this sample.