If a Supabase service_role or secret key was exposed in frontend code, treat it as a privileged-credential incident. Identify the key type, stop distributing it, retire the compromised credential through the appropriate Supabase procedure and assess what happened during the exposure window. Removing the current variable does not revoke copies already obtained.
A publishable key or legacy anon key is a different case: those are designed for public clients, with access controlled through grants, authentication and policies. This checklist helps an application owner distinguish the two situations and coordinate containment. It is a response plan, not evidence that a breach did or did not occur.
Key takeaways
- Classify the actual credential before treating every visible Supabase key as a secret.
- Privileged credentials bypass RLS; policy changes alone do not contain their exposure.
- Inventory legitimate server callers before completing the replacement and retirement sequence.
- Verify revocation and investigate impact as separate outcomes.
Identify what was shipped and where
Supabase's current key documentation distinguishes publishable and secret keys from their legacy anon and service_role equivalents. Secret and service_role credentials have elevated access. Confirm the type in the project's authorized settings rather than guessing from a variable name. Never paste the value into an incident ticket or chat.
Record where the credential appeared: a JavaScript bundle, mobile release, source repository, build log or public file. Note the earliest known publication and the last release known to contain it. Preserve restricted evidence using a fingerprint or approved reference rather than copying the secret into another broadly accessible system.
If the key is public by design, review the access rules it can reach instead. That review may still reveal a consequential exposure, but the remedy is different from rotating an elevated credential. Use the linked tenant-isolation guide for that boundary assessment.
Contain the exposure path and inventory legitimate callers
Stop the build or configuration path that places the privileged value in shipped code. Rebuild the affected artifact with the correct public-client configuration. Look for copies in generated files and historical releases as well as the source line. Removing the frontend use prevents another release from repeating the problem; it does not make the old credential safe.
At the same time, identify the legitimate backend components that use the credential. Name an owner for each and the approved location where its replacement will be configured. A small inventory helps you contain the incident without leaving a forgotten job running with the old value.
If there is evidence of active misuse or a serious exposure, the incident owner may need immediate revocation even if that causes a controlled service interruption. Make that decision from the observed incident and available controls, not from a blanket rule to preserve availability at all costs.
| Component | Intended privilege | Replacement evidence |
|---|---|---|
| Browser or mobile application | Public client with user-scoped access. | New shipped artifact contains no privileged credential. |
| Administrative API | Server-only access after authorization. | Owner confirms replacement and a permitted administrative exercise. |
| Scheduled worker | Only the work assigned to the controlled backend job. | A representative run uses the replacement; old configuration removed. |
| Deployment configuration | Build and runtime values separated appropriately. | Configuration names reviewed without exposing their values. |
Follow the procedure for the actual key system
For a compromised secret key, follow the current Supabase replacement and retirement instructions. For a legacy service_role key, the migration and legacy-key controls differ. Creating a new key is not proof that the compromised legacy credential has stopped working.
Supabase's signing-key documentation explains the relationship between legacy JWT-based API keys and signing-key changes. Do not rotate an unrelated signing mechanism casually or assume that changing one setting revokes every credential. Check the current project controls and the affected clients before applying the chosen sequence.
Keep the credential replacement in approved secret-management channels. Restrict access to the incident record and deployment logs. If repository history needs cleanup, coordinate it after containment; rewriting history cannot revoke a key already copied elsewhere.
Review the credential boundary and the corrected release.
Share a sanitized incident timeline and the intended application architecture through approved channels. We can scope the review without collecting credentials in the inquiry.
Verify containment, then investigate the exposure window
Containment evidence should show that the compromised credential fails on the relevant access path and that legitimate callers work with the replacement. Use a controlled verification that avoids retrieving customer data. Review the new frontend artifact separately; a successful backend test does not prove the next bundle is clean.
Impact assessment asks another question: what access or changes occurred while the credential was exposed? Review available access records, database changes, unexpected jobs and relevant storage activity with the incident owner. Missing telemetry limits the conclusion. No obvious error in the application is not evidence that no data was accessed.
Record known facts, unresolved questions and the next investigative step. If personal or regulated data may be affected, involve the appropriate organizational incident process and jurisdiction-specific advisers. This checklist does not determine reporting obligations for every market.
Close with a release check that prevents recurrence
A useful closure record distinguishes the clean replacement release, confirmed credential retirement and the remaining impact investigation. For example, 'frontend artifact corrected; old privileged access rejected; historical access assessment still open' is precise. 'Security fixed' conceals important unfinished work.
Add a deployment check suited to the original failure: client configuration review, restricted server imports, generated-artifact inspection or secret scanning. Verify it using a harmless synthetic marker or controlled fixture rather than deliberately distributing another real secret. Assign an owner for the check.
MUBBITS can help review the affected application and the release boundary. Bring a sanitized incident timeline and your intended backend callers through approved channels; keep production credentials out of the inquiry itself.
Frequently asked questions
Is a Supabase key visible in the browser always a leak?
No. Publishable and legacy anon keys are intended for public clients. Confirm the actual type and examine the permissions they can reach. Secret and service_role credentials must remain in controlled backend components.
Will enabling RLS stop a leaked privileged key?
No. Elevated keys bypass RLS. Contain the credential through the appropriate key controls and separately review the application's customer-scoped permissions.
Does removing a key from Git prove containment?
No. Copies may remain in history, artifacts or someone else's possession. Confirm that the compromised credential no longer works and that the distribution path has been corrected.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.