--- title: "Appwrite vs Supabase drošība: vienādi uzbrukumi abiem" description: "Tos pašus piekļuves uzbrukumus palaidu uz Appwrite 2.3.0 un lokāla Supabase. Abi aizslēdz jaunas tabulas; atšķiras kļūdas gaita un tas, ko atver atslēga." url: "https://madsalt.tech/lv/blog/appwrite-vs-supabase/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/lv/about/" language: "lv" published: 2026-10-30 --- # Appwrite vs Supabase drošība: vienādi uzbrukumi abiem Īsumā Abi jaunu tabulu pēc noklusējuma aizslēdz: Appwrite viesim un pierakstītam lietotājam atbildēja `401`, bet Supabase atbild `401`/`403`, kamēr tabulai nepiešķirat tiesības API lomām. Atšķirība parādās, kad noteikums ir kļūdains vai pieprasījums šķērso lietotāju robežu. Uz Supabase cita lietotāja rindas update atgrieza `200 []`, un brīva insert politika ļāva lietotājam pievienoties citam uzņēmumam; uz Appwrite katrs mēģinājums šķērsot lietotāju robežu manā testā beidzās ar `401` vai `404`, un lietotājs nevarēja nodot savu rindu nevienam, tikai sev pašam vai visiem. Appwrite servera atslēgām ir apjomi (scopes); Supabase secret key izlaiž katru politiku. Esmu Denys, full-stack un AI inženieris. Lielākā daļa lietotņu, ko veidoju vai labāju, darbojas uz Supabase, un klienti, kas vēl izvēlas backend, jautā, kā ar drošību ir Appwrite. Funkciju saraksti uz to neatbild, tāpēc abiem nosūtīju vienus un tos pašus pieprasījumus. **Kā testēju.** Appwrite 2.3.0, pašmitināts (self-hosted) ar Docker 2026. gada 30. oktobrī, caur REST API kā viesis, kā divi pierakstīti lietotāji A un B un ar divām servera atslēgām. Supabase puse ir mans palaidums lokālā stekā (CLI 2.109.1, Postgres 17.6) 2026. gada 24. oktobrī ar tām pašām lomām, pilnībā aprakstīts rakstā [Supabase RLS policy piemēri, pārbaudīti caur API](https://madsalt.tech/lv/blog/supabase-rls-policy-examples/). Abās pusēs izdomātas rindas. ## Kā Appwrite un Supabase aizsargā datus? Supabase tabulas aizsargā ar Postgres: grant nosaka, vai API lomas vispār tiek pie tabulas, un rindu līmeņa drošības (RLS) politikas, rakstītas SQL, nosaka, kādas rindas katrs pieprasījums redz un raksta. Appwrite atļaujas glabā blakus datiem: tabulai ir lomu saraksts, kurām atļauts lasīt, veidot, atjaunināt vai dzēst, un, ieslēdzot rindu drošību (row security), katrai rindai ir savs saraksts. Saskaņā ar [Appwrite atļauju dokumentāciju](https://appwrite.io/docs/products/databases/tablesdb/permissions) piekļuve tiek tikai piešķirta, nekad neatņemta, un lietotājam tā vajadzīga tabulas vai rindas līmenī, ne abos. Tātad jautājums nav, kuram ir piekļuves kontrole. Abiem ir. Jautājums ir, kur katrs ļauj pieļaut kļūdu. ## Ko katrs dara ar jaunu tabulu? | Pieprasījums | Appwrite, atļaujas nav iestatītas | Supabase, RLS ieslēgts, bez granta (24. okt.) | | ------------------------------ | ------------------------------------------------- | --------------------------------------------- | | Viesis nolasa rindas | `401` user_unauthorized | `401` permission denied | | Pierakstīts lietotājs nolasa | `401` user_unauthorized | `403` permission denied | | Pierakstīts lietotājs pievieno | `401` No permissions provided for action 'create' | netestēts | Jauna tabula abos ir slēgta. Supabase tā ir jaunums: tabulas, kas izveidotas pēc 2026. gada 30. oktobra, Data API grantus vairs automātiski nesaņem, par ko rakstīju rakstā [30. oktobra grantu izmaiņas](https://madsalt.tech/lv/blog/supabase-october-30-grant-change/). ## Kas notiek, kad tabula ir atvērta visiem? Abi „atvērtie” iestatījumi nav viens un tas pats. Appwrite tabulai piešķīru vienu atļauju, `read("any")`. Supabase ierastais atvērtais stāvoklis ir izslēgts RLS ar atstātiem noklusējuma grantiem. | Viesa pieprasījums | Appwrite, `read("any")` | Supabase, RLS izslēgts, noklusējuma granti (24. okt.) | | ------------------ | ----------------------- | ----------------------------------------------------- | | Nolasīt rindas | `200`, abas rindas | `200`, abas rindas | | Dzēst rindu | `401` | `200`, abas rindas izdzēstas | Appwrite „publisks” nozīmē tikai lasīšanu, ja vien nepiešķirat arī rakstīšanu. Supabase tabulu ar izslēgtu RLS var lasīt un rakstīt ikviens, kam ir publishable key, tāpēc „RLS disabled in public” ir pirmais, ko pārbaudu. ## Kā darbojas „savas rindas”? Appwrite ieslēdzu rindu drošību un tabulai piešķīru vienu atļauju, `create("users")`. Kad A izveidoja rindu, nenorādot atļaujas, Appwrite tās iestatīja pats: `read`, `update` un `delete` tikai lietotājam A. Supabase tam pašam mērķim vajadzīgas četras politikas ar `(select auth.uid()) = user_id`. | Pieprasījums | Appwrite (30. okt.) | Supabase (24. okt.) | | -------------------- | ------------------- | ------------------------- | | Viesis nolasa rindas | `200`, 0 rindu | `401` (`anon` bez granta) | | A nolasa rindas | `200`, A 2 rindas | `200`, A 2 rindas | | A lasa B rindu | `404` row_not_found | sarakstā neatgriež | | A atjaunina B rindu | `401` | `200 []` | | A dzēš B rindu | `401` | `200 []` | ![Viens pieprasījums, divi backend. Lietotājs A rediģē lietotāja B rindu caur katra REST API. Supabase, tikai īpašnieka politika: Lietotājs A → maina B rindu → 200 \[\] → 0 rindu, bez kļūdas; Appwrite, rindu drošība ieslēgta: Lietotājs A → maina B rindu → 401 → atgriezta kļūda.](https://madsalt.tech/charts/lv/appwrite-vs-supabase.svg) *1. att. Mani testi: lokāls Supabase steks (CLI 2.109.1), 2026. gada 24. oktobris; self-hosted Appwrite 2.3.0, 2026. gada 30. oktobris.* Neviens neizpaudis B rindu. Atšķiras atbilde. Supabase filtrē rindas, ko politika slēpj, tāpēc update, kas neatbilda nekam, ir veiksme ar nulle rindām; lietotne, kas „nav kļūdas” uzskata par „saglabāts”, pasaka lietotājam, ka viņa izmaiņas izdevās. Appwrite atsaka ar kļūdu, ko lietotne nevar nepamanīt. ## Vai lietotājs var nodot savus datus citam? Šeit ģenerēts kods kļūdās visbiežāk, tāpēc izmēģināju abos. | A pieprasījums | Appwrite | Supabase (24. okt.) | | ---------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------- | | Izveidot rindu, ko var lasīt lietotājs B | `401`, Permissions must be one of: any, users, user:A… | atkarīgs no politikas | | Mainīt savu rindu, lai tā piederētu B | `401`, tas pats ziņojums | `403` ar pilnu `with check`; `200` ar `with check (true)` | | Izveidot rindu, ko var lasīt visi | `201`, un viesis to pēc tam nolasīja | tikai ja politika atļauj | Appwrite ierobežo, ko lietotājs var piešķirt: tikai lomas, kas pašam ir, proti, `any`, `users`, viņa paša lietotājs un viņa komandas. Tas bloķēja gājienu „iedod manu rindu kādam citam” bez jebkāda mana noteikuma. Tas neapturēja A publicēt savu rindu visiem ar `read("any")`. Ja rindai nekad nedrīkst būt publiskai, atļaujas nedrīkst iestatīt klients; veidojiet to no servera funkcijas. Uz Supabase iznākums ir tāds, ko saka politika. Pilns `with check` noraidīja pārcelšanu ar `403`; `with check (true)`, ko raksta daži ģeneratori, ļāva A pārcelt rindu uz B kontu. ## Vai lietotājs var pievienoties cita uzņēmuma komandai? Uz Supabase komandas piekļuve parasti ir `memberships` tabula plus politikas. Manā testā insert politika, ko iesaka daudzas pamācības, `with check (user_id = auth.uid())`, ļāva A pievienot sevi 2. uzņēmumam ar `201 Created` un pēc tam lasīt tā algu projektu. Appwrite komandas (teams) ir iebūvētas. B izveidoja komandu; A mēģināja pievienoties kā dalībnieks un kā īpašnieks. Abi pieprasījumi atgrieza `404 team_not_found`: A komandu pat neredzēja. Dalību nosaka serveris, nevis jūsu rakstīts noteikums, tāpēc šī konkrētā noplūde nav iespējama. Lai rindas varētu koplietot, joprojām vajag `read("team:…")` atļaujas, un tās iestatāt paši. ## Ko atver servera atslēga? | Atslēga | Appwrite | Supabase (no mana anon vs service role testa) | | -------------------------------------- | ----------------------------------- | --------------------------------------------- | | Pilna servera atslēga | `200`, visas 4 abu lietotāju rindas | visas 3 rindas, RLS izlaists | | Atslēga ar šauru apjomu (`users.read`) | `401`, missing scope rows.read | apjomu atslēgu nav | Supabase secret key atbilst `service_role`, kam ir `BYPASSRLS`; ko tā atver, ir rakstā [anon key vs service role key](https://madsalt.tech/lv/blog/supabase-anon-key-vs-service-role-key/). Appwrite atslēga arī ignorē rindu atļaujas, bet tikai tiem apjomiem, ar kādiem tā izveidota, tāpēc atslēga lietotāju pārvaldības uzdevumam nevar nolasīt jūsu tabulas. Jebkura atslēga pārlūka pakotnē ir pilnīga noplūde visam, ko tā sasniedz. Divi sīkāki atradumi uz Appwrite: viesis un pierakstīts lietotājs, pieprasot tabulu sarakstu, abi saņēma `401` (izsaukumam vajag `tables.read`, kas ir tikai atslēgām), un `read("users")` nozīmē jebkuru pierakstītu kontu, tas pats slazds kā `auth.uid() is not null` uz Supabase, kad reģistrācija ir atvērta. ## Kurš ir drošāks? Neviens nav drošs vai nedrošs pēc noklusējuma; abi sākās slēgti. Tie atšķiras ar to, kur var slēpties kļūda: | Jautājums | Appwrite | Supabase | | ----------------------------------------------- | ------------------------------------ | ----------------------------------------------- | | Kur dzīvo piekļuves noteikumi | Lomu saraksti tabulās un rindās | SQL granti un politikas | | Noraidīts cita lietotāja rakstīšanas mēģinājums | Kļūda (`401` / `404`) | `200` ar nulle rindām update un delete gadījumā | | Rindu piešķiršana citiem | Tikai lomām, kas pašam lietotājam ir | Kā atļauj politika | | Noteikumi pēc kolonnu vērtībām, MFA līmenis | Atļaujās to nav; vajag servera kodu | Politikā, piemēram, `aal2` jutīgām rindām | | Servera atslēgas | Ar apjomiem | Secret key izlaiž visas politikas | Appwrite modelis ir šaurāks, un manā testā šaurais modelis noraidīja katru triku starp lietotājiem, man neko neierakstot. Supabase modelis ir SQL, tāpēc tas var izteikt noteikumus, ko Appwrite atļaujas nevar, piemēram, „tikai ar MFA” vai „tikai to uzņēmumu rindas, kuriem piederu”, un tas var izteikt arī nepareizu noteikumu. Ja jūsu komanda politikas nelasīs, Appwrite noklusējumi piedod vairāk. Ja vajag noteikumus, kas atkarīgi no datiem, Supabase ļauj tos uzrakstīt, un tad tie jātestē; metode, ko izmantoju, ir rakstā [kā es testēju Supabase RLS](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/). ## Kā pārbaudīt Supabase projektu? Bezmaksas [Supabase drošības pārbaude](https://madsalt.tech/lv/tools/supabase-security-check/) nolasa jūsu projektu tikai lasīšanas režīmā un atzīmē tabulas ar izslēgtu RLS, vienmēr patiesas politikas, rakstīšanas politikas viesiem un grantus, kas dod vairāk, nekā politikas paredz. Ko Supabase aizsargā jūsu vietā un ko atstāj jums, ir rakstā [vai Supabase ir drošs?](https://madsalt.tech/lv/blog/is-supabase-secure/). Appwrite ekvivalenta tajā nav; Appwrite palaidiet augstāk minētos pieprasījumus kā divi lietotāji. Firebase gadījumā es palaidu tāda paša veida uzbrukumus rakstā [Firebase security rules piemēri](https://madsalt.tech/lv/blog/firebase-security-rules-examples/). **Ierobežojumi.** Viens pašmitināts Appwrite 2.3.0 klēpjdatorā un viens lokāls Supabase steks, palaisti ar sešu dienu starpību, izdomātas rindas. Appwrite Cloud var atšķirties no self-hosted. Storage, funkcijas, realtime, auth iestatījumi un atbilstības sertifikāti šeit netiek salīdzināti. Izvēlaties backend lietotnei ar privātiem datiem? Labprāt kopā ar jums apskatīšu jūsu piekļuves modeli. Bez pārdošanas sarunas. [Sazināties](https://madsalt.tech/lv/#contact)