Supabase phone sign-up is enabled with public registration
ShipReady found published Supabase settings showing the phone provider enabled while public sign-up remains open.
Why it matters
Phone sign-up can be intentional, but it should have an explicit abuse and cost-control design because a public registration flow may initiate SMS delivery.
How ShipReady detects it
What it inspects
After discovering a Supabase project and public anon key from client content, ShipReady reads the published auth settings document for phone-provider and public-signup values.
What triggers a finding
The rule triggers when the settings report the external phone provider enabled and sign-up not disabled.
What the evidence shows
The observed settings document reports an enabled phone provider together with public registration.
Limits of this check
ShipReady does not submit a sign-up, send an SMS, inspect CAPTCHA, rate limiting, provider spending limits, regional restrictions, or application fraud controls. It does not prove that SMS abuse or unexpected charges occurred.
How to fix it
Confirm that public phone registration is required
Disable the phone provider or public sign-up if the product does not need that registration path.
Review controls around the actual SMS flow
Configure the relevant rate limits, challenge controls, monitoring, provider restrictions, and server-side policies for the intended audience.
How to verify the change
Exercise the intended registration flow safely
Use controlled test numbers and accounts to verify expected enrollment, rate-limit, and provider behavior without relying on the scanner result alone.
Expected: Only intended sign-up requests can initiate the intended phone verification flow.