Które zasady bezpieczeństwa aplikacji dla firmy obowiązują od pierwszego dnia?

Model zagrożeń: kto i czym realnie uderza w aplikację dla firmy?

Zagrożenie w aplikacji dla firmy rzadko wygląda jak włamanie. Pięć z sześciu scenariuszy w tabeli niżej to zwykłe żądanie wysłane przez kogoś, kto ma konto albo zna adres — nikt niczego nie łamie, po prostu prosi o cudze dane i je dostaje.

Model zagrożeń nie jest listą technologii. To odpowiedź na cztery pytania: kto, czym, co firma traci i która zasada to wyklucza. Jeśli przy którymś wierszu nie umiesz wskazać zasady, ta dziura jest po prostu otwarta.

Kolejność nie jest przypadkowa. W zestawieniu OWASP Top 10:2025, które grupuje ryzyka aplikacji webowych w dziesięć kategorii, pozycję pierwszą zajmuje Broken Access Control — czyli dokładnie to, co robią trzy pierwsze wiersze tabeli (odczyt 31.08.2026).

Siedem zasad, które muszą wejść pierwszego dnia

Każda z nich kosztuje kilka minut przy zakładaniu projektu i kilka tygodni po starcie, kiedy trzeba ją dołożyć do działającej aplikacji z prawdziwymi kontami i prawdziwymi płatnościami. Dlatego mówimy „pierwszego dnia”, a nie „przed startem produkcyjnym”.

1. Sekrety poza kodem i poza frontem. Klucze i hasła żyją w ustawieniach dostawcy, nie w repozytorium i nie w kodzie strony.

   Błąd, który wyklucza: klucz sekretny wklejony do frontu albo do pliku w projekcie.

   Koszt błędu: dokumentacja Supabase mówi wprost, że klucz sekretny działa przez rolę z atrybutem bypassrls, czyli pomija polityki dostępu, i nigdy nie ma prawa trafić do przeglądarki (odczyt 31.08.2026).

2. Polityki dostępu na wierszach na każdej tabeli wystawionej przez API. Błąd, który wyklucza: tabela w wystawionym schemacie bez polityk.

   Koszt błędu: dokumentacja Supabase formułuje to bez ozdobników — taka tabela jest do odczytu i do zapisu dla każdej roli, która ma na niej uprawnienie.

   Same polityki też nie wystarczą: dopóki nie odbierzesz domyślnych uprawnień, rola anonimowa zachowuje ścieżkę zapisu.

   Do tego obowiązuje u nas reguła kontrolna: uprawnienia nadane na kolumny bez polityk na wiersze są pozorne. Po każdej zmianie widoku sprawdzamy też ustawienie security_invoker, bo podmiana widoku potrafi je zgubić i widok zaczyna omijać polityki.

3. Administrator po roli, nie po zalogowaniu. Błąd, który wyklucza: polityka, w której całym warunkiem jest rola authenticated.

   Koszt błędu: każdy zalogowany klient jest administratorem. Dokumentacja Supabase opisuje tę rolę jako „żądanie uwierzytelnione (użytkownik jest zalogowany)” — to informacja o tym, że ktoś się zalogował, a nie o tym, kim jest.

   Uprawnienie administratora sprawdzamy po identyfikatorze użytkownika w osobnej tabeli ról.

4. Identyfikator w adresie to nie hasło. Błąd, który wyklucza: link „bez logowania”, który otwiera się samym identyfikatorem rekordu. Koszt błędu: cudze dane po zmianie jednej cyfry, czyli pierwsza kategoria zestawienia OWASP. Linki działające bez logowania dostają u nas token z terminem ważności i zakresem — identyfikator rekordu nie może otwierać cudzych danych.

5. Webhook płatności jest jedynym źródłem prawdy o wpłacie. Front nigdy nie zalicza płatności sam: kwota i status zapisują się z powiadomienia operatora, nie z przekierowania po zapłacie.

   Błąd, który wyklucza: zapis „opłacone” na powrocie z bramki albo powiadomienie przyjmowane bez weryfikacji podpisu.

   Koszt błędu: Stripe pisze to wprost — bez weryfikacji napastnik może wysłać fałszywe zdarzenie i wywołać realizację zamówienia, przyznanie dostępu albo zmianę rekordów.

   Z tej samej dokumentacji dwie liczby do ustawienia: biblioteki Stripe domyślnie odrzucają podpis starszy niż 5 minut, a ponowne próby doręczenia idą w trybie produkcyjnym nawet przez trzy dni. Obsługa musi więc być odporna na powtórkę tego samego zdarzenia (odczyt 31.08.2026).

6. Kopie sprawdzane odtworzeniem, nie istnieniem pliku. Błąd, który wyklucza: „kopie robią się codziennie” jako odpowiedź na pytanie o kopie.

   Koszt błędu: o tym, że kopia jest niepełna, dowiadujesz się w dniu, w którym jest jedyna. Punkt odtworzenia (ile danych tracisz) i czas odtworzenia (jak długo aplikacja nie działa) zapisujemy, zanim będą potrzebne.

   Uwaga na plan u dostawcy: lista kontrolna Supabase przed startem produkcyjnym mówi, że w planie darmowym kopii bazy nie da się pobrać, a odtworzenie do wybranego momentu jest płatnym dodatkiem (odczyt 31.08.2026).

7. Klucz, który mógł wyciec, rotujesz od razu. Błąd, który wyklucza: dyskusja, czy na pewno ktoś go widział. Koszt błędu: czas, w którym stary klucz nadal działa, a usunięcie pliku nie usuwa go z historii zmian. Rotacja trwa minuty, ustalanie kto miał dostęp — dni.

Jedna pułapka przy samodzielnym sprawdzaniu uprawnień. Lista pobrana przez API bazy jest domyślnie ucinana — w konfiguracji Supabase parametr max_rows stoi na 1000. Sam PostgREST zachowuje się inaczej: bez tego ustawienia nie ogranicza wyniku wcale (odczyt 31.08.2026).

Skutek jest podstępny. Audyt „kto ma dostęp” na trzech tysiącach kont pokaże komplet zgodny z oczekiwaniem, bo dalszych wierszy po prostu nie zobaczysz. Każde pobranie listy ma u nas jawny limit i stronicowanie — także wtedy, gdy służy do kontroli, a nie do wyświetlenia.

Jak to sprawdzić samemu w 5 minut?

Pięć testów, do których wystarczy przeglądarka, telefon i jedno pytanie do wykonawcy. Żaden nie wymaga umiejętności programowania i żaden nie psuje danych. Razem zajmują około pięciu minut.

1. Wyloguj się i wklej link do panelu (30 sekund). Ma przekierować do logowania. Jeśli pokazuje treść, te dane są publiczne dla każdego, kto zna adres.
2. Zaloguj się jako zwykły klient i zmień cyfrę w adresie rekordu (60 sekund). Oczekiwana odpowiedź to komunikat o braku dostępu. Cudzy rekord w tym miejscu przesądza całą resztę listy.
3. Sprawdź, czy repozytorium jest prywatne, i poszukaj klucza w kodzie strony (60 sekund). W przeglądarce: podgląd źródła strony i wyszukanie słów „secret” oraz „service”. Klucz publikowalny w kodzie frontu jest w porządku, sekretny nie ma tam czego szukać.
4. Zapytaj o datę ostatniego odtworzenia kopii (30 sekund). Dobra odpowiedź brzmi: „dnia X, odtworzenie trwało Y, straciliśmy Z minut danych”. Odpowiedź „kopie robią się codziennie” mówi o pliku, nie o odtworzeniu.
5. Zapłać najmniejszą możliwą kwotą i zamknij kartę przed powrotem na stronę (90 sekund). Zamówienie ma się i tak zapisać jako opłacone, bo status pochodzi z powiadomienia operatora. Jeśli zostaje nieopłacone, płatność zalicza front — a to znaczy, że można ją też zaliczyć bez płacenia.

Wynik negatywny nie jest powodem do awantury z wykonawcą, tylko listą zadań. Trzy pierwsze punkty poprawia się w godzinach, dopóki aplikacja nie ma jeszcze tysięcy kont i lat historii.

Co mówi prawo: RODO artykuł 32 i 33?

Dwa artykuły rozporządzenia 2016/679 zamieniają część powyższej listy z dobrej praktyki w obowiązek. Poniżej brzmienie przepisu, nie jego interpretacja.

Artykuł 32 ustęp 1 nakazuje administratorowi i podmiotowi przetwarzającemu wdrożyć środki odpowiednie do ryzyka i wymienia wprost cztery: pseudonimizację i szyfrowanie danych, zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów, zdolność do szybkiego przywrócenia dostępności danych po incydencie oraz regularne testowanie i ocenianie skuteczności zastosowanych środków.

Dwie z tych czterech pozycji to dokładnie zasada szósta z listy wyżej. Litera c mówi o zdolności do szybkiego przywrócenia danych, litera d o regularnym testowaniu skuteczności. Kopia, której nikt nigdy nie odtworzył, nie spełnia żadnej z nich.

Artykuł 33 ustęp 1 daje na zgłoszenie naruszenia organowi nadzorczemu 72 godziny od jego stwierdzenia, bez zbędnej zwłoki i w miarę możliwości w tym terminie. Wyjątek dotyczy sytuacji, gdy jest mało prawdopodobne, by naruszenie skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych. Do zgłoszenia przekazanego po 72 godzinach dołącza się wyjaśnienie przyczyn opóźnienia.

Praktyczny skutek dotyczy logów. Zgłoszenie musi opisać charakter naruszenia i w miarę możliwości podać kategorie oraz przybliżoną liczbę osób i wpisów, których dotyczy (artykuł 33 ustęp 3). Bez zapisu, kto i do czego sięgał, nie da się tego wypełnić, a zegar w tym czasie idzie.

Artykuł 33 ustęp 5 nakazuje dokumentować wszystkie naruszenia, także niezgłoszone, tak by organ mógł zweryfikować przestrzeganie tego artykułu. Ocena konkretnego zdarzenia należy do administratora danych i jego prawnika. Tutaj podajemy wyłącznie brzmienie przepisu i miejsce, w którym każdy może je sprawdzić u źródła.

Co z tym zrobić, zanim ruszy budowa?

Siedem zasad i pięć testów wpisuje się do dokumentu zakresu jako wymaganie, nie jako życzenie. Zdanie „polityki dostępu na wierszach włączone na każdej tabeli wystawionej przez API” da się sprawdzić w piętnaście minut. Zdanie „aplikacja będzie bezpieczna” nie da się sprawdzić nigdy.

Dwie pozycje z tej listy zależą od decyzji podjętych wcześniej. Wybór operatora płatności i sposób obsługi powiadomienia o wpłacie omawia zestawienie płatności w pierwszej wersji aplikacji, a rachunek utrzymania w dłuższym oknie — tekst o koszcie aplikacji w trzy lata.

Jeśli aplikacja ma w środku model językowy, do listy dochodzą terminy z osobnego kalendarza, zebrane w tekście o terminach AI Act dla aplikacji z AI. Zasady z tej strony obowiązują niezależnie od tego, co siedzi pod spodem.

Czego w tym tekście nie ma: liczby sekretów, jaką pomieści konfiguracja funkcji brzegowych. Wiemy z praktyki, że taki limit istnieje — od pewnej liczby integracji trzymamy konfigurację jako jeden dokument JSON zamiast osobnych zmiennych.

Konkretnej liczby nie podajemy, bo nie znaleźliśmy jej w dokumentacji na dzień 31 sierpnia 2026. Bezpieczeństwa nie planuje się na szacunkach.