TL;DR
Julkinen bucket tarjoaa jokaisen sen tiedoston kenelle tahansa, jolla on URL, ilman avainta ja kirjautumista: storage-politiikkojasi ei kysytä latauksen yhteydessä. Paikallisella stackillani sama testitiedosto palautti 200 ja sisällön julkisesta bucketista ja 400 yksityisestä. Lataukset palvelimelle, poistot ja siirrot kulkevat edelleen politiikkojen kautta. Käytä julkisia bucketeja tiedostoille, jotka ovat luonnostaan julkisia, kuten avatarit ja artikkelikuvat, ja yksityisiä bucketeja allekirjoitettujen URL-osoitteiden kanssa kaikelle muulle.
Ilmaisessa Supabase-tietoturvatarkistuksessani on kaksi bucketeja koskevaa sääntöä: “Julkiset storage-bucketit” listaa ne, jotta voit varmistaa, että jokaisen kuuluu olla julkinen, ja “Julkiset bucketit ilman latausrajoja” liputtaa julkiset bucketit, joilla ei ole koko- tai tiedostotyyppirajaa. Tässä on, mitä julkinen-lippu todella muuttaa.
Mitä julkinen bucket tarkoittaa Supabasessa?
Supabasen bucket-opas määrittelee kaksi pääsymallia. Yksityisessä bucketissa jokainen operaatio, lataukset mukaan lukien, kulkee storage.objects-taulun RLS-politiikkojen kautta; tiedosto luetaan käyttäjän tokenilla tai allekirjoitetulla URL:lla, joka vanhenee. Julkisessa bucketissa tiedostojen haku ja tarjoaminen ohittaa pääsynhallinnan, joten kuka tahansa, jolla on URL, voi lukea tiedoston. Pääsynhallinta koskee edelleen tiedostojen lähettämistä, poistamista, siirtämistä ja kopioimista.
Bucketit ovat oletuksena yksityisiä. Bucketista tulee julkinen, kun joku ruksaa ruudun Dashboardissa tai luo sen asetuksella public: true, mikä on yleinen oikotie, kun kuva ei lataudu.
Mitä kumpikin bucket palautti testissäni?
Paikallisella Supabase-stackilla (CLI 2.109.1) loin yhden julkisen ja yhden yksityisen bucketin, latasin saman pienen tekstitiedoston molempiin secret keyllä ja pyysin sitten sitä ilman avainta, kuten linkin saanut tuntematon tekisi:
Pyyntö tiedostolle 2026/invoice-001.txt |
Julkinen bucket | Yksityinen bucket |
|---|---|---|
/storage/v1/object/public/…, ei avainta |
200, tiedoston sisältö |
400, “Bucket not found” |
/storage/v1/object/authenticated/…, vain publishable key |
200 |
400 |
Yksityinen bucket vastaa kuin sitä ei olisi, ja juuri sitä haluat. Julkinen antaa tiedoston kenelle tahansa, joka osaa arvata tai löytää polun.
Miksi URL on niin tärkeä?
Julkinen tiedosto on yhtä salainen kuin sen polku. Polut ovat usein ennustettavia: käyttäjätunnus, päivämäärä, laskunumero. Ne myös vuotavat sivun lähdekoodin, jaettujen linkkien, selainhistorian ja lokien kautta. Lasku, passikopio tai allekirjoitettu sopimus julkisessa bucketissa on käytännössä julkaistu.
Miten valitset ja korjaat?
- Julkinen bucket: kaikille tarkoitetut tiedostot, kuten avatarit, tuotekuvat ja blogikuvat. Aseta bucketille tiedostokokoraja ja sallitut MIME-tyypit, jotta politiikkojesi sallimaa julkista latausreittiä ei voi käyttää mihinkään muuhun hostaukseen.
- Yksityinen bucket: asiakirjat, viennit, laskut, kaikki henkilökohtainen. Lataa käyttäjän istunnolla tai luo allekirjoitettu URL, joka vanhenee.
Näin näet bucketisi ja niiden rajat:
select id, public, file_size_limit, allowed_mime_types
from storage.buckets
order by public desc, id;
Yksityinen bucket tarvitsee myös politiikat storage.objects-tauluun, yleensä tarkistuksen, että polun ensimmäinen kansio on käyttäjän tai yrityksen tunnus. Projektin siirron jälkeen laske nämä politiikat: yhdessä sovelluksessa jokainen lataus epäonnistui, koska politiikkamigraatiota ei ajettu koskaan, mistä kirjoitin Lovable-sovelluksen tietoturvatarkistuslistassani. Mihin muuhun publishable key yltää, selviää artikkelista Supabase anon key vs service role key.