Bezpieczeństwo
Szyfrowanie zero-knowledge
Dane planu są szyfrowane po stronie klienta (AES-GCM). Klucz szyfrujący wyprowadzamy z hasła użytkownika (PBKDF2), a w planie Duo udostępniamy go między domownikami przez wymianę kluczy (ECDH). Klucz nie trafia na serwer w żadnej postaci. Nie piszemy własnej kryptografii — korzystamy z natywnego Web Crypto API przeglądarki.
Skutek: nawet z pełnym dostępem do bazy nie da się odczytać danych użytkownika bez jego hasła lub kodu odzyskiwania.
Kontrola dostępu (Row Level Security)
W trybie chmurowym dostęp do danych egzekwuje Postgres RLS: zapytania widzą i
modyfikują wyłącznie gospodarstwo, którego jesteś członkiem. Operacje takie jak
tworzenie/dołączanie/opuszczanie gospodarstwa czy zapis stanu przechodzą przez
funkcje security definer, które w kontrolowany sposób sprawdzają uprawnienia.
RLS działa jako dodatkowa warstwa (defense-in-depth) na szyfrogramie — ogranicza,
kto w ogóle pobierze rekord, choć i tak jest on nieczytelny bez klucza.
Klucze i sekrety
- W przeglądarce używany jest wyłącznie publiczny klucz
anon, chroniony przez RLS. - Klucze wrażliwe (np. service-role, klucze dostawcy płatności) nigdy nie trafiają do frontendu — żyją tylko po stronie serwera (zmienne środowiskowe).
- Brak sekretów w repozytorium.
Walidacja danych
Każdy formularz i każdy odczyt ze stanu przechodzi przez schematy Zod — nieprawidłowe lub złośliwe dane nie trafiają do aplikacji. Teksty są oczyszczane ze znaków kontrolnych.
Hasła
Hasła nie są przechowywane jawnie — Supabase trzyma jedynie jednokierunkowy hash (bcrypt). Nie da się ich odczytać; można je tylko zresetować lub nadpisać.
Operacje destrukcyjne
Reset danych i usunięcie konta wymagają potwierdzenia hasłem, aby zapobiec przypadkowej utracie danych.
Transport i nagłówki
Komunikacja po HTTPS, z nagłówkami bezpieczeństwa (m.in. CSP).