Supabase anonymous sign-ins are enabled
ShipReady found the anonymous-users setting enabled in the project's published Supabase auth settings.
Why it matters
Anonymous sign-ins can be an intentional guest-flow feature, but application controls must distinguish an anonymous session from a verified or registered user when that distinction matters.
How ShipReady detects it
What it inspects
After discovering a Supabase project and public anon key from client content, ShipReady reads the project's published auth settings document.
What triggers a finding
The rule triggers when the settings document reports anonymous users enabled.
What the evidence shows
The observed published settings document reports anonymous sign-ins enabled for the project.
Limits of this check
ShipReady does not create an anonymous session, call an Edge Function, inspect Row Level Security policies, assess application routes, or determine what an anonymous user can access or spend. The setting alone does not prove that a protected action is publicly usable.
How to fix it
Decide whether guest sessions are needed
Disable anonymous sign-ins if the product does not need guest sessions, or document the specific flows that require them.
Authorize sensitive actions explicitly
Require the necessary identity, verification, role, or server-side authorization for data access and cost-incurring operations instead of treating any session as sufficient.
How to verify the change
Test as an anonymous session
Use a controlled anonymous session to test the intended guest flow and sensitive application actions.
Expected: Anonymous sessions can perform only the actions intentionally granted to guests.