FixVibe

// docs / baas security / supabase storage

Supabase biltegiratze-ontziaren segurtasun-zerrenda: 22 elementu

Supabase Storage S3-rekin bateragarria den ontzi baten gainean bildurik dagoen geruza mehe bat da, gehi datu-basearen errenkada-mailako segurtasun-eredu berdina. Horrek esan nahi du tauletan eragiten dituzten RLS hutsuneak berberek eragiten dietela fitxategi-sarbideei — eta IA kodetze-tresnek igoerak konektatzen dituztenean agertzen diren biltegiratzeari berariazko gutxi batzuk. Zerrenda hau bost ataletan banatutako 22 elementu da: ontzien konfigurazioa, RLS politikak, igoeraren baliozkotzea, sinatutako URLak eta higiene operatiboa. Bakoitza 15 minutu baino gutxiagotan egiaztatu daiteke.

Beheko elementu bakoitza ezinbestekoa da. Azpiko RLS mekanikari buruzkoa, ikus Supabase RLS eskanerra. Biltegiratzearekin lotutako gako-agerpen klasea, ikus Supabase service role gakoa JavaScript-en agerian.

Ontzien konfigurazioa

Hasi lehenetsi egokiekin. Gaizki konfiguratutako ontzi batek fitxategiak iragazten ditu zure RLS zuzena izan ala ez.

  1. Lehenetsi ontzi bakoitza pribatura. Supabase aginte-panelean → Storage → Buckets, ezarri Public bucket aldagai-botoia itzalita zergati esplizitu bat ez baduzu (marketin-aktiboak, PII gabeko abatar publikoak). Ontzi publikoek RLS saihesten dute irakurketa-eragiketetarako — ontziaren izena duen edonork zerrendatu eta deskargatu dezake.
  2. Ezarri fitxategi-tamaina muga gogor bat ontzi bakoitzean. Aginte-panela → Bucket settings → File size limit. 50 MB lehenetsi zentzudun bat da erabiltzaileen igoeretarako; hazi nahita bideo / fitxategi handi kasuetarako. Mugarik gabe, igoera maltzur bakar batek zure biltegiratze-kuota edo zure hileko banda-zabalera agortu dezake.
  3. Mugatu MIME mota baimenduak ontzi bakoitzeko. MIME mota baimenduen zerrenda — baimen-zerrenda esplizitua, ez blokeo-zerrenda. image/jpeg, image/png, image/webp irudi soileko ontzietarako. Inoiz ez baimendu text/html, application/javascript edo image/svg+xml erabiltzaileen edukiaren ontzi batean — sinatutako URL bidez zerbitzatzen direnean nabigatzailean exekutatzen dira.
  4. Erabili ontzi bat eduki-mota bakoitzeko, ez ontzi partekatu bakar bat. Ontzi-bakoitzeko ezarpenak (tamaina, MIME motak, RLS politikak) dituzun granularitatea dira. user-avatars ontzi bat, document-uploads ontzi bat eta public-assets ontzi bat errazago blokeatu daitezke ontzi nahasi bakar bat baino.
  5. Egiaztatu CORS konfigurazioa frontend-igoerak egiten badira. Erabiltzaileek nabigatzailetik sinatutako URL batera zuzenean igotzen badute, ontziaren CORSak zure ekoizpen-jatorria zerrendatu behar du. * ontzi publikoetarako bakarrik onargarria da — inoiz ez erabiltzaileen PII duten ontzietarako.

storage.objects-eko RLS politikak

Supabase Storage-k fitxategien metadatuak storage.objects taulan gordetzen ditu. Taula horretako RLSk nor irakurtzen, kargatzen, eguneratzen edo ezabatzen duen fitxategiak kontrolatzen du. RLSrik gabe, ontziaren publiko/pribatua dela zure babes bakarra da.

  1. Berretsi RLS gaituta dagoela storage.objects-en. SELECT rowsecurity FROM pg_tables WHERE schemaname = 'storage' AND tablename = 'objects'; true itzuli behar du. Supabasek lehenetsia gaitzen du proiektu berrietan; egiaztatu desgaituta ez dagoela.
  2. Idatzi SELECT politika bat auth.uid()-ra mugatuta ontzi pribatuetarako. CREATE POLICY "users_read_own_files" ON storage.objects FOR SELECT USING (auth.uid()::text = (storage.foldername(name))[1]);. Konbentzioa fitxategiak [user-id]/[filename] azpian gordetzea da eta storage.foldername() erabiltzea jabea bidetik ateratzeko.
  3. Idatzi INSERT politika bat bide-konbentzio bera betearazten duena. CREATE POLICY "users_upload_own" ON storage.objects FOR INSERT WITH CHECK (auth.uid()::text = (storage.foldername(name))[1]);. WITH CHECK gabe, autentikatutako erabiltzaile batek beste erabiltzaile baten karpetan igo dezake.
  4. Gehitu UPDATE eta DELETE politikak zure aplikazioak fitxategi-edizioak edo ezabaketak onartzen baditu. Komando bakoitzak bere politika behar du. DELETE saltatzeak esan nahi du autentikatutako erabiltzaileek ezin dituztela bere fitxategiak kendu; UPDATE saltatzeak esan nahi du fitxategi-gainidazketek isilean huts egiten dutela.
  5. Proba erabiltzaile arteko sarbidea bi nabigatzaile-saiotan. Eman izena A erabiltzaile gisa, igo fitxategi bat, kopiatu bidea. Eman izena B erabiltzaile gisa beste nabigatzaile batean, saiatu fitxategia REST APIaren bidez eskuratzen. Erantzuna 403 edo 404 izan behar du, inoiz ez 200.
sql
-- Confirm RLS on storage.objects
SELECT rowsecurity
FROM   pg_tables
WHERE  schemaname = 'storage' AND tablename = 'objects';

-- SELECT policy: scope reads to the owning user's folder.
CREATE POLICY "users_read_own_files"
  ON storage.objects
  FOR SELECT
  USING (auth.uid()::text = (storage.foldername(name))[1]);

-- INSERT policy: enforce the [user-id]/[filename] path convention.
CREATE POLICY "users_upload_own"
  ON storage.objects
  FOR INSERT
  WITH CHECK (auth.uid()::text = (storage.foldername(name))[1]);

Igoeraren baliozkotzea

Baliozkotu igoera bakoitza zerbitzariaren aldetik, baita ontziak MIME eta tamaina-mugak dituenean ere. IA kodetze-tresnek bezero-soilik baliozkotzea sortzen dute lehenetsita; horrek ez du ezer babesten.

  1. Berriz egiaztatu MIME mota zerbitzariaren aldetik fitxategiaren benetako byte-tatik, ez Content-Type goiburutik. Erabili file-type (Node) bezalako liburutegi bat edo magic-byte usnaketa. Erasotzaile batek Content-Type: image/jpeg aldarrika dezake benetan poliglota HTML / JavaScript karga bat den fitxategi batean.
  2. Kendu EXIF metadatuak igotako irudietatik. EXIFek GPS koordenatuak, gailuaren serie-zenbakiak eta denbora-zigiluak izan ditzake. Erabili sharp .withMetadata(false)-rekin edo exif-parser biltegiratu aurretik kentzeko.
  3. Errefusatu script etiketak edo onload kudeatzaileak dituzten SVGak. SVG XML da — eta IAk sortutako aplikazio askok SVG igoerak baimentzen dituzte "irudi bat baino ez balira bezala". Erabili DOMPurify zerbitzariaren aldetik edo errefusatu SVG igoerak guztiz.
  4. Erabili deterministiko eta asmaezinezko fitxategi-izenak. Ez gorde jatorrizko fitxategi-izena. Erabili UUID bat edo fitxategiaren edukiaren hash bat. Jatorrizko fitxategi-izenek iragazten dute ("pasaporte_eskaneatzea_2024_01_15.jpg") eta aurreikus daitezkeen izenek zenbaketa ahalbidetzen dute.

Sinatutako URLak

Sinatutako URLak bezeroek ontzi pribatuetara nola sartzen diren da. Iraungitzea, ontziaren esparrua eta zer erregistratzen den garrantzitsuak dira.

  1. Lehenetsi sinatutako URLen iraungitzea ordubete edo gutxiagora. Supabase JS SDK-ren createSignedUrl(path, expiresIn) segundoak hartzen ditu. Inoiz ez erabili 31536000 bezalako balioak (urtebete) — URLa esteka erdi-publiko iraunkor bihurtzen da.
  2. Inoiz ez gorde sinatutako URLak zure datu-basean. Sortu berriak zerbitzariaren aldetik eskaera bakoitzean. Urtebeteko iraungitzea duen gordetako sinatutako URL bat datu-basearen iraulketa baten bidez iragazten denean, epe luzeko sarbidea ematen du.
  3. Erregistratu sinatutako URLen sorrera, ez bakarrik fitxategi-igoerak. Geroago konpromiso bat susmatzen baduzu, jakin behar duzu nork sortu zuen zein URL noiz. Erregistratu auth.uid() + ontzia + objektuaren bidea + denbora-zigilua.
  4. Erabili downloadAs aukera erabiltzaileek igotako fitxategiak zerbitzatzean. createSignedUrl(path, expiresIn, { download: '.jpg' })-k Content-Disposition: attachment goiburua behartzen du, beraz, fitxategia errenderizatu beharrean deskargatzen da — HTML / SVG / HTML-PDF-an exekuzio klasea garaitzen du.

Higiene operatiboa

Biltegiratzearen konfigurazioak denboran zehar dabilkete. Lau elementu operatibo hauek azalera estu mantentzen dute.

  1. Auditatu ontziak hiruhilekoetan. Aginte-panela → Storage → Buckets. Berretsi publiko/pribatu egoera eta MIME-moten zerrendak aplikazioak espero duenarekin bat datozela. "Aldi baterako" sortutako ontziak betikoak bihurtzen dira inork ez baditu kentzen.
  2. Monitorizatu zerrendatze-eragiketa anonimoak. Biltegiratze-erregistroek (Aginte-panela → Logs → Storage) LIST eskaerak erregistratzen dituzte. Ontzi pribatu baten aurkako anonimoko zerrendatze-eskaeren gorakada batek esan nahi du norbait kanpotik miatzen ari dela.
  3. Ezarri atxikitze-politika igoera iragankorretarako. Aldi baterako ontziek (irudi-aurrebista, zirriborro igoerak) 24-72 ordu igarota auto-ezabatu beharko lukete antolatutako funtzio baten bidez. Atxikitze mugagabea zama bat da GDPR / CCPA datuen minimizazio-betebeharren arabera.
  4. Egin FixVibe eskaneatze bat hilero. baas.supabase-storage-public egiaztapenak GET + LIST anonimoei erantzuten dieten ontziak miatzen ditu. Ontzi berriak gehitzen dira; zaharrek ikusgaitasuna aldatzen dute — etengabeko eskaneatzeak baino ez du jasotzen jariotzea.

Hurrengo urratsak

Egin FixVibe eskaneatze bat zure ekoizpen-URLaren aurka — biltegiratze-zerrendatze anonimoak baas.supabase-storage-public azpian agertzen dira. Bikoiztu zerrenda hau Supabase RLS eskanerra taula-geruzarako eta Supabase service role gakoa JavaScript-en agerian gako-agerpenaren auzotasunarekin. Beste BaaS hornitzaileen biltegiratze-konfigurazio okerrak ezagutzeko, ikus BaaS konfigurazio okerren eskanerra.

// eskaneatu zure baas azalera

Aurkitu taula irekia beste norbaitek aurkitu baino lehen.

Sartu ekoizpen-URL bat. FixVibek zure aplikazioak hitz egiten dituen BaaS hornitzaileak zerrendatzen ditu, beren amaiera-puntu publikoen hatz-marka egiten du eta autentikatu gabeko bezero batek zer irakurri edo idatzi dezakeen jakinarazten du. Doan, instalaziorik gabe, txartelik gabe.

  • Doako maila — 3 eskaneatze hilean, izen-eman txartelik gabe.
  • BaaS hatz-marka pasiboa — ez da behar domeinu-egiaztapenik.
  • Supabase, Firebase, Clerk, Auth0, Appwrite eta gehiago.
  • IA konponketa-gonbitak aurkikuntza bakoitzean — itsatsi berriz Cursor / Claude Code-en.
Egin doako BaaS eskaneatze bat →

ez da izen-ematerik behar

Supabase biltegiratze-ontziaren segurtasun-zerrenda: 22 elementu — Docs · FixVibe