templates
Storage Safety templates
How to prevent bucket and object enumeration, accidental public file access, and user data leaks through Supabase Storage. This page collects practical templates and explains how this category fails in real Supabase apps — plus the safest fix patterns to apply.
What Storage Safety means for Supabase security
Storage exposure often happens when buckets are public or listing is allowed. A safe default is private buckets + signed URLs generated server-side, with predictable filenames avoided.
Storage Safety templates in this library
| Template | Best for | URL |
|---|---|---|
| Make a bucket private + serve files with signed URLs | A template to make Supabase Storage buckets private, prevent listing/enumeration, and deliver downloads using short-lived signed URLs from your backend. | /templates/storage-safety/make-bucket-private-signed-urls |
How Storage Safety fails in real apps
- Relying on “logged in” as authorization (authenticated ≠ authorized).
- Assuming policies work when RLS is disabled.
- Using broad conditions that don’t bind rows to a user/tenant.
- Fixing one table but leaving storage/RPC exposed.
How to fix Storage Safety issues safely
- Start by removing direct client access to sensitive resources.
- Centralize authorization in backend endpoints.
- Use RLS as an additional safety gate (not the only one).
- Verify fixes with direct access tests and re-scans.
Verification checklist for Storage Safety fixes
- Identify the exact surface you’re changing (table, bucket, function).
- Apply the template and keep a rollback path (feature flag or staged rollout) if possible.
- Attempt direct access using client credentials (it should fail after the fix).
- Confirm the app still works via backend endpoints for authorized users.
- Re-run a scan and re-run any SQL checklist queries you use for drift detection.
Common pitfalls when applying Storage Safety templates
- Treating policies as the only control instead of also removing direct client paths.
- Forgetting to repeat the same hardening steps in production (drift between environments).
- Locking down reads but leaving writes exposed (or vice versa).
- Fixing the database but leaving Storage/RPC surfaces publicly accessible.
- Skipping verification and assuming “the UI works” means “it’s secure.”
Related glossary terms
- Supabase Storage Bucket Privacy →
/glossary/supabase-storage-bucket-privacy - Signed URLs →
/glossary/signed-urls
How Storage Safety connects to conversions and examples
If you need the “full story” (not just copy/paste SQL), use these cross-playbook links:
- Conversions explain the entire unsafe → safe transformation and reduce missed steps.
- Examples show how the exposure shipped and how to verify your fix is real.
Use sibling category pages to broaden coverage, then return to the templates to apply changes with verification.
How to adapt Storage Safety templates to your schema
- Replace table/bucket/function names carefully and double-check you didn’t widen access accidentally.
- If you have multi-tenant data, make sure every rule binds rows to a tenant boundary (not just “logged in”).
- Prefer smaller, verifiable changes over large refactors; ship one fix, verify, then repeat.
- After applying a template, re-run the same direct access test you used to validate the risk.
Quick validation questions for Storage Safety
Use these questions to confirm you picked the right category and template before you make breaking changes:
- Can I access the resource directly without going through my backend?
- If I revoke client access, do I have a backend endpoint ready to replace it?
- Do I know how to prove the fix worked (one direct access test)?
- Am I fixing all environments (dev/staging/prod) or only one?
Next steps
Pick one template, apply it in staging, and run the verification checklist.
Then re-scan so you catch drift before it becomes an incident.
FAQ
What’s the fastest Storage Safety improvement with the highest impact?
Remove direct client access to sensitive resources and route reads/writes through a backend layer. This reduces exposure even when policies are imperfect.
Do I have to use every template in Storage Safety?
No. Choose templates that match real, validated risks in your project. If you can’t validate a risk, don’t ship a disruptive change “just in case.”
How do I keep fixes from regressing?
Add a repeatable checklist (or automated checks) that runs after schema changes, and periodically re-scan production configuration.
Next step
If you want these templates to match your exact schema and exposure, scan your project in Mockly and follow the linked fixes.