Pereiti prie turinio

Ar Supabase saugus? Ką jis apima, o ką turite jūs

Žiūrėti kaip MarkdownAtidaryti per ClaudeAtidaryti per ChatGPTAtidaryti per Perplexity

Klausimas taip pat nukopijuojamas. Jei pokalbis atsidaro tuščias, įklijuokite jį.

Trumpai

Taip, platforma saugi: Supabase sertifikuotas pagal SOC 2 Type 2 ir ISO 27001, šifruoja duomenis AES-256 saugojimo metu ir TLS perduodant bei pasirašo HIPAA sutartis Team plane ir aukštesniuose. Jūsų projektas yra kitas klausimas. Pagal Supabase bendros atsakomybės modelį (shared responsibility model) prieiga prie lentelių, API raktai ir auth nustatymai yra jūsų, o platforma daro tiksliai tai, ką šie nustatymai nurodo. Mano vietinėje bandomojoje lentelėje vienas nustatymas lėmė, ar viešasis raktas gavo 0 eilučių, ar visas 3.

Esu Denys, full-stack ir AI inžinierius, ir dauguma programų, kurias kuriu ar taisau, veikia ant Supabase. Klientai klausia „ar Supabase saugus?“, turėdami omenyje „ar mano duomenys saugūs?”. Atsakymai skirtingi, todėl šiame straipsnyje juos nagrinėju po vieną.

Ar Supabase platforma saugi?

Platformos pusę audituoja trečiosios šalys. Iš Supabase saugos puslapio ir saugos dokumentacijos, perskaityta 2026 m. spalio 23 d.:

Kontrolė Ką teigia Supabase
SOC 2 Type 2 Audituojama kasmet; ataskaita prieinama Team ir Enterprise klientams
ISO 27001 Sertifikuota; sertifikatas prieinamas Team ir Enterprise klientams
HIPAA Palaikoma su pasirašyta Business Associate Agreement ir HIPAA priedu, Team planas ir aukštesni
Šifravimas AES-256 saugomiems duomenims, TLS perduodamiems; prieigos tokenai ir raktai papildomai šifruojami programos lygiu
Atsarginės kopijos Kasdienės mokamiems projektams; Point in Time Recovery kaip priedas nuo Pro plano
Duomenų vieta Duomenų bazė, Auth ir Storage lieka jūsų pasirinktame AWS regione

Nė viena iš šių priemonių neapsaugo lentelės, kurią palikote atvirą. SOC 2 vadovas tai sako tiesiai: Supabase atitiktis neperkeliama niekam, kas yra už jos kontrolės ribų.

Kokia jūsų dalis?

Supabase shared responsibility model išvardija tai, kas visada jūsų: jūsų paskyra, prieigos valdymas prie duomenų bazės ir jos lentelių, jūsų duomenys ir saugos kontrolių taikymas, įskaitant įspėjimus, kuriuos iškelia Security Advisor. Praktiškai tai reiškia keturis nustatymų sluoksnius:

Kas saugo kiekvieną užklausos žingsnį. Supabase valdo perdavimą ir raktus; teisės ir politikos yra jūsų. Iš naršyklės: Naršyklė → TLS, raktas · Supabase → Teisė · jūs → RLS · jūs; Iš jūsų serverio: Serveris → TLS · Supabase → Secret key · jūs → RLS praleistas.
1 pav. Pagal Supabase shared responsibility model ir API keys vadovą, 2026 m. spalis.
  1. Kas gali liesti lentelę. Teisės (grants) nusprendžia, ar anon ir authenticated apskritai pasiekia lentelę. RLS politikos nusprendžia, kurias eilutes.
  2. Kuris raktas kur eina. Publishable key pagal paskirtį yra viešas, secret key apeina RLS. Palyginau juos straipsnyje Supabase anon key vs service role key.
  3. Auth nustatymai. El. pašto patvirtinimas, leaked password protection (Pro planas ir aukštesni), mažiausias slaptažodžio ilgis, MFA, redirect URL, CAPTCHA.
  4. Viskas aplink duomenų bazę. Storage bucket ir jų politikos, SECURITY DEFINER funkcijos, Edge Function, naudojančios secret key, ir kurias schemas Data API atveria.

Kiek pakeičia vienas nustatymas?

Paleidau tą pačią užklausą vienai lentelei su trimis išgalvotais užsakymais vietinėje Supabase aplinkoje (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), su publishable key, kaip tai darytų naršyklė:

Lentelės nustatymas Ką gavo viešasis raktas
RLS išjungtas Visos 3 eilutės, o įterpimas grąžino 201 Created
RLS įjungtas, politikos nėra []
RLS įjungtas, politika using (true) Visos 3 eilutės
Rolė anon neturi teisės 42501 permission denied

Ta pati platforma, tas pats šifravimas, tie patys sertifikatai. Skirtumas yra viena SQL eilutė. Todėl „saugi platforma” ir duomenis nutekinanti programa nėra prieštara: CVE-2025-48757 rado 170 iš 1645 Lovable demonstracinių programų, atidavusių duomenis viešajam raktui, visas toje pačioje audituotoje platformoje.

Ar Supabase pagal numatytuosius nustatymus tampa saugesnis?

Taip, žingsnis po žingsnio. Supabase 2026 m. balandžio 28 d. changelog išvardija RLS-on-by-default jungiklį, Data API atvirumo ženklą, lentelių lygio teises ir schemų išvardijimo apribojimą. Didžiausias pakeitimas įsigalioja 2026 m. spalio 30 d.: naujoms esamų projektų lentelėms Data API teisės automatiškai nebesuteikiamos, todėl užmiršta lentelė vietoj eilučių grąžins 42501. Esamos lentelės teises išsaugo, todėl tai nieko neištaiso to, kas jau atvira. Seni anon ir service_role raktai taip pat laikomi pasenusiais iki 2026 m. pabaigos publishable ir secret key naudai; naujas secret key atmeta užklausas iš naršyklės.

Ką dar sugadina perjungimas ir kaip patikrinti projektą iš anksto: Supabase spalio 30 d. pokytis: kas sulūš ir kaip patikrinti.

Kaip patikrinti savo projektą?

Pradėkite nuo paties Supabase Security Advisor ir ištaisykite kiekvieną įspėjimą. Tada patikrinkite tai, ko jis neapima:

  • Paleiskite nemokamą Supabase saugos tikrintuvą. Jis jungiasi tik skaitymo režimu ir vertina projektą pagal 46 taisykles, susietas su OWASP Top 10:2025: RLS, politikos, view, funkcijos, teisės, storage ir auth nustatymai, kiekvienam radiniui pateikiant taisomąjį SQL.
  • Testuokite su dviem vartotojais dviejose įmonėse. Joks skeneris nežino, kurios eilutės kam priklauso; testas aprašytas mano Lovable programos saugos sąraše.
  • Jei jūsų programoje yra rolės ir leidimų ekranas, įrodykite, kad kiekvienas leidimo langelis daro tai, ką sako, kaip straipsnyje kaip testuoju Supabase RLS.

Taigi: Supabase yra saugi vieta duomenims laikyti ir suteikia įrankius jiems išlaikyti privačius. Ar jie liks privatūs, sprendžiama jūsų schemoje ir nustatymuose.

Svarstote Supabase savo projektui?

Mielai palyginsiu patirtį, ką nustatyti pirmiausia. Be pardavimų kalbų.

Susisiekti

© 2026 Denys Zaichenko. Originalus straipsnis: https://madsalt.tech/lt/blog/is-supabase-secure/