pezkuwichain 0fe8c85dfe fix(security): identify the caller from their token, not the request body ...

two-factor-auth and notifications-manager run with the service role, so they
bypass RLS and whatever user id they act on is the entire authorisation
decision. Both read that id from the request body, and neither checked who was
calling. Access-Control-Allow-Origin was '*' on both.

Confirmed against the live endpoint: with only the public anon key and no user
session, from an arbitrary origin,

  POST /functions/v1/two-factor-auth {"action":"check","userId":"<any-uuid>"}
  -> 200 {"success":true,"enabled":false}

VERIFY_JWT is on and does not stop this, because the anon key is itself a valid
JWT and every browser has it. The same path reaches "disable", so anyone could
turn off another account's 2FA, and read, delete or forge their notifications.

The client already sends the signed-in user's token — functions.invoke puts the
session access token in the Authorization header — so the caller can simply be
read from it. Both functions now do that and ignore the body's userId. An
anon-key call carries no user, so it is rejected with 401.

create is the one action that may target someone else, because AdminPanel
notifies other users; that path now requires admin or super_admin in
admin_roles. CORS drops to the same allowlist the other functions here use.

No frontend change: the body may keep sending userId, it is simply not read.

Note: 2FA is not yet enforced at login — TwoFactorVerify is not referenced
anywhere and Login.tsx never checks it, so enrolling does not currently protect
sign-in. Tracked separately; this change is about the endpoints themselves.

2026-07-30 04:05:03 -07:00

..

index.ts

fix(security): identify the caller from their token, not the request body

2026-07-30 04:05:03 -07:00