Supabase service-role credential marker appears in public content
ShipReady found either a JWT declaring the service_role role or a supported Supabase secret-key pattern in public content.
Why it matters
Service-role credentials belong only in trusted server environments because they are intended for privileged backend operations.
How ShipReady detects it
What it inspects
ShipReady scans page content and fetched scripts. It decodes JWT-shaped values only to read the role claim and also recognizes the supported Supabase secret-key format.
What triggers a finding
The rule triggers for a JWT with a service_role claim or for the supported Supabase secret-key pattern. An anon JWT and other JWT roles are excluded.
What the evidence shows
The scanner observed one of the supported service-role credential markers in public content.
Limits of this check
ShipReady does not use the credential, connect to a Supabase project, enumerate tables, test Row Level Security, or establish that the credential is active.
How to fix it
Keep privileged credentials server-side
Remove service-role material from browser build inputs and place it in server-only secret management.
Rotate the affected credential
Use Supabase project controls to rotate an exposed or uncertain credential and update trusted server deployments.
How to verify the change
Inspect client artifacts
Confirm deployed HTML and JavaScript contain only intended public configuration such as an anon key.
Expected: No service-role JWT marker or secret-key pattern is shipped to browsers.