Public Storage Bucket Check — Are User Uploads World-Readable?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
A publicly readable storage bucket gives every uploaded file a plain URL — avatars, documents, anything users trust you with is world-readable and shareable.
Why AI tools generate it
AI app builders set storage buckets public-read because uploads 'just work'; nothing in the app shows the difference between an upload succeeding and it being world-readable.
How DevMeth detects it
A live scan fetches only the objects your own code names (bucket and key references found in your repo) with anonymous GETs — a 200 with content is a finding. Guessing, listing endpoints, and write paths are never touched.
Your storage bucket is readable by anyone on the internet
WHAT WE FOUND
C41 — masked sample
The fix, in three steps
Make the bucket private and serve files through short-lived signed URLs behind your session check — then re-evaluate what was exposed.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
Only avatars are in that bucket — is that bad?
Avatars-by-design can be public. The review question is whether EVERYTHING in the bucket is meant to be public — buckets mix content, and the one private document uploaded 'temporarily' is the leak.
How did you test this without listing my whole bucket?
Your own code names the buckets and object paths it uses — we fetched exactly those, anonymously, the way any visitor could. No listing endpoints, no guessing, nothing written.
What's the fix?
Private bucket + short-lived signed URLs served behind your session check. Supabase: Storage → Policies. S3: Block Public Access + getSignedUrl.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.