Bezpieczeństwo aplikacji webowych: checklista i standardy

Bezpieczeństwo aplikacji webowych to zestaw zabezpieczeń kodu, konfiguracji, danych i sposobu pracy zespołu, które razem utrudniają kradzież danych, przejęcie kont i unieruchomienie systemu. Poniżej dostajesz checklistę elementów, które ją budują, a przy każdym z nich standardy, do których się odnosi: OWASP, ISO 27001, RODO i NIS2.

W Poldevs wykonujemy audyty kodu, audyty bezpieczeństwa i testy penetracyjne, więc piszę z perspektywy wykonawcy, który takie aplikacje ogląda od środka. Adresuję ten tekst do właścicieli firm, którzy zamawiają lub utrzymują oprogramowanie i chcą wiedzieć, o co zapytać wykonawcę. Jeśli dopiero porządkujesz wiedzę o tym, czym jest taka aplikacja, zacznij od artykułu co to jest aplikacja webowa.

Bezpieczeństwo aplikacji webowych - co to jest i co obejmuje?

Bezpieczna aplikacja webowa chroni trzy rzeczy: poufność danych (widzą je tylko uprawnione osoby), integralność (nikt nie zmienia ich po cichu) i dostępność (system działa, gdy jest potrzebny). Żadne pojedyncze narzędzie nie zapewnia wszystkich trzech naraz. Ochronę buduje kilkadziesiąt drobnych decyzji: jak wygląda logowanie, kto widzi czyje dane, jak wyglądają zapytania do bazy, gdzie leżą hasła do zewnętrznych usług, co się dzieje po awarii.

Za te decyzje odpowiadają trzy strony. Wykonawca odpowiada za kod i konfigurację aplikacji, dostawca hostingu lub chmury za infrastrukturę, a Ty, jako właściciel, za to, kto ma dostęp, jakie dane zbierasz, ile płacisz za utrzymanie i czy w ogóle zamawiasz sprawdzenie. Wiele luk wynika z niewypowiedzianych założeń: wykonawca zakłada, że kopie robi hosting, hosting zakłada, że kopie robi wykonawca, a Ty zakładasz, że ktoś to sprawdza.

Skalę problemu pokazują dane, które OWASP zebrał do edycji Top 10:2025. Wszystkie aplikacje w tej próbie miały jakąś formę błędu kontroli dostępu i jakąś formę błędnej konfiguracji (OWASP, A01:2025; OWASP, A02:2025). To dane z aplikacji sprawdzonych przez organizacje, które je przekazały, więc opisują ogólne ryzyko i nie mówią, ile błędów ma Twoja aplikacja.

Drugi punkt odniesienia to raport Verizon DBIR 2026, obejmujący incydenty z okresu od 1 listopada 2024 r. do 31 października 2025 r. Według raportu 31% naruszeń zaczyna się od podatności w oprogramowaniu, co czyni je częstszą drogą wejścia niż skradzione hasła (Verizon, 2026 Data Breach Investigations Report). Wartość pochodzi z próby naruszeń zbadanych w raporcie i nie jest prognozą dla Twojej firmy. Pokazuje jednak, że bezpieczeństwo trzeba świadomie zamówić.

Jak zabezpieczyć aplikację webową? Odpowiedź w skrócie

Moim zdaniem największy efekt przy rozsądnym koszcie dają pięć rzeczy. Pełna checklista poniżej ma ponad czterdzieści pozycji, ale od nich warto zacząć.

Dla nowej aplikacji rekomenduję zestaw szerszy: konta imienne z rolami i dokumentacją uprawnień, walidację danych po stronie frontendu i backendu, sekrety poza repozytorium, rozdzielone środowiska, udokumentowany proces wdrażania zmian z przeglądem kodu, nagłówki bezpieczeństwa oraz logi zdarzeń dostępne dla uprawnionej osoby po stronie biznesu. Pełna lista z numerami wymagań jest w tabelach checklisty poniżej. Kolejność wynika z OWASP Top 10:2025: błędy kontroli dostępu i konfiguracji zajmują dwa pierwsze miejsca, a awarie łańcucha dostaw trzecie. O tym, jak sprawdza się to w praktyce, piszę w artykule o testach penetracyjnych.

Porada 1:

Przejdź z wykonawcą po tabelach z tej checklisty i zapytaj o każdy wiersz: wdrożone, planowane czy świadomie pominięte. Odpowiedź „pominięte, bo ryzyko jest małe” jest w porządku, jeśli ktoś to ryzyko faktycznie ocenił.

Do jakich standardów odnosi się bezpieczeństwo aplikacji webowych?

Standardy mają różny charakter: jedne to przepisy, inne normy do certyfikacji, jeszcze inne listy ryzyk i wymagań technicznych. Do aplikacji webowej odnoszą się wszystkie, ale na różnych poziomach. Poniższa tabela porządkuje te, które pojawiają się w checkliście.

OWASP Top 10:2025 w dziesięciu zdaniach

OWASP oparł edycję 2025 na danych z ponad 2,8 mln aplikacji, a do analizy wziął 589 typów słabości (CWE). W stosunku do edycji 2021 doszła kategoria A10, A03 rozszerzyła dawne „przestarzałe komponenty” o cały łańcuch dostaw, a SSRF włączono do A01 (OWASP, Top 10:2025 - wprowadzenie). Tabela pokazuje, co znaczy każda kategoria i które elementy checklisty ją pokrywają. Średni współczynnik występowania pochodzi z opisów kategorii (top10.owasp.org/2025) i opisuje próbę aplikacji przekazanych OWASP, więc nie jest prognozą dla Twojej aplikacji.

OWASP ASVS i API Security Top 10:2023

ASVS (Application Security Verification Standard) opisuje konkretne wymagania numerowane według rozdziałów, na przykład 6.2.1 to minimalna długość hasła. Wersja 5.0.0 ukazała się 30 maja 2025 r. i ma rozdziały od V1 (kodowanie i sanityzacja) do V17 (WebRTC). W checkliście korzystam z rozdziałów V1-V8 oraz V11-V16, bo dotyczą typowych aplikacji webowych. Dla interfejsów API istnieje osobna lista z 2023 r., która wyróżnia m.in. autoryzację na poziomie obiektu (API1) i nieograniczone zużycie zasobów (API4).

NIST SSDF

SSDF (SP 800-218, wersja 1.1 z lutego 2022 r.) dzieli praktyki na cztery grupy: przygotowanie organizacji (PO), ochrona oprogramowania (PS), tworzenie dobrze zabezpieczonego oprogramowania (PW) i reagowanie na podatności (RV). Wersja 1.2 (SP 800-218 Rev. 1) została w grudniu 2025 r. opublikowana jako projekt do konsultacji (NIST), dlatego w tabelach odwołuję się do wersji 1.1 i podaję praktyki na poziomie grup, na przykład PW.5 (bezpieczne kodowanie).

ISO/IEC 27001:2022 i CIS Controls v8.1

Norma ISO/IEC 27001:2022 opisuje system zarządzania bezpieczeństwem informacji całej organizacji, a jej załącznik A ma 93 kontrole. Do aplikacji odnoszą się głównie kontrole technologiczne, na przykład A.8.5 (bezpieczne uwierzytelnianie), A.8.28 (bezpieczne kodowanie) i A.8.29 (testy bezpieczeństwa). Tekst normy jest płatny, dlatego podaję numery i nazwy kontroli, a przypisanie ich do elementów checklisty to moja ocena. CIS Controls v8.1 ma 18 kontroli; używam ich na poziomie całej kontroli (np. CIS 5 to zarządzanie kontami, CIS 11 to odtwarzanie danych).

RODO art. 32 i przykład z decyzji UODO

Art. 32 ust. 1 RODO wymaga od administratora i podmiotu przetwarzającego środków technicznych i organizacyjnych dobranych do ryzyka. Wskazuje przykłady: pseudonimizację i szyfrowanie (lit. a), zdolność do zapewnienia poufności, integralności, dostępności i odporności systemów (lit. b), zdolność do przywrócenia dostępu do danych po incydencie (lit. c) oraz regularne testowanie i ocenianie skuteczności tych środków (lit. d). Ust. 2 każe uwzględniać ryzyko przypadkowego lub bezprawnego zniszczenia, utraty, zmiany lub ujawnienia danych (rozporządzenie (UE) 2016/679, EUR-Lex). Przepis nie wskazuje konkretnych technologii, więc listy takie jak ASVS pomagają zamienić „odpowiednie środki” na sprawdzalne wymagania.

Jak wygląda to w praktyce regulatora, pokazuje sprawa spółki Morele.net. Co się wydarzyło: według komunikatu UODO doszło dwukrotnie do nieuprawnionego dostępu z zewnątrz i do wycieku danych osobowych 2,2 mln osób. Co potwierdzono: Prezes UODO w decyzji z 17 stycznia 2024 r. nałożył na spółkę karę ponad 3,8 mln zł, ustalając m.in., że część danych nie była szyfrowana, spółka nie miała uwierzytelniania dwuskładnikowego, nie przeprowadziła analizy ryzyka obejmującej na przykład logowanie z sieci publicznych i nie miała narzędzi do monitorowania ruchu sieciowego (UODO, Prezes UODO ponownie ukarał spółkę Morele.net, 8.02.2024). WSA oddalił skargę spółki na tę decyzję wyrokiem z 16 września 2024 r. (UODO, WSA oddalił skargę Morele.net). Czego nie wiadomo: spółka nie miała pewności, czy i jakie dane zostały wykradzione. Wniosek dla zamawiającego: pytania o MFA, szyfrowanie, analizę ryzyka i monitoring z tej checklisty dotyczą tych samych zabezpieczeń, których brak UODO ujął w uzasadnieniu kary.

NIS2 i ustawa o krajowym systemie cyberbezpieczeństwa

Art. 21 ust. 2 dyrektywy NIS2 wylicza dziesięć grup środków, między innymi analizę ryzyka (lit. a), obsługę incydentów (lit. b), ciągłość działania z kopiami zapasowymi (lit. c), bezpieczeństwo łańcucha dostaw (lit. d), bezpieczeństwo w nabywaniu, rozwoju i utrzymaniu systemów wraz z obsługą podatności (lit. e), kryptografię (lit. h) oraz uwierzytelnianie wieloskładnikowe (lit. j) (dyrektywa (UE) 2022/2555, EUR-Lex). Do polskiego prawa wdraża ją ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252), obowiązująca od 3 kwietnia 2026 r. (Dziennik Ustaw, ELI). Przepisy dotyczą podmiotów kluczowych i ważnych z sektorów wskazanych w ustawie. Pozycje NIS2 w tabelach pokazują, do czego odnoszą się poszczególne zabezpieczenia.

Czy RODO dotyczy mojej aplikacji?

RODO dotyczy Twojej aplikacji, jeśli przetwarza dane osobowe, na przykład konta użytkowników, dane kontaktowe lub zamówienia. Wtedy art. 32 wymaga od administratora i podmiotu przetwarzającego środków technicznych i organizacyjnych dobranych do ryzyka, w tym szyfrowania, zdolności przywrócenia danych i regularnego testowania skuteczności zabezpieczeń.

Czy NIS2 obejmuje moją firmę?

Objęcie NIS2 zależy od sektora, wielkości i rodzaju działalności firmy. W Polsce dyrektywę wdraża ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252), obowiązująca od 3 kwietnia 2026 r. Przepisy dotyczą podmiotów kluczowych i ważnych z sektorów wskazanych w ustawie, więc sprawdź to w jej załącznikach lub z prawnikiem.

Czy potrzebuję certyfikatu ISO 27001, żeby aplikacja była bezpieczna?

Certyfikat ISO 27001 potwierdza system zarządzania bezpieczeństwem informacji całej organizacji i jest potrzebny głównie wtedy, gdy klient lub audytor go oczekuje. Norma ma 93 kontrole w załączniku A (wersja 2022), z których do aplikacji odnoszą się głównie kontrole technologiczne, na przykład uwierzytelnianie, bezpieczne kodowanie i testy bezpieczeństwa.

Czy ISO 27001 to to samo co zgodność z ASVS?

ISO 27001 i ASVS opisują różne rzeczy. ISO 27001 ma 93 kontrole na poziomie organizacji, a ASVS 5.0.0 wymagania na poziomie aplikacji, z trzema poziomami weryfikacji. OWASP nie certyfikuje zgodności z ASVS i zaleca ostrożność wobec ofert, które powołują się na taki certyfikat.

Jak czytać checklistę i poziomy ASVS?

Każda z dziewięciu grup poniżej zaczyna się od tabeli, w której przy elemencie stoją pozycje z poszczególnych standardów. Pozycje OWASP Top 10 i API Top 10 pochodzą z opisów kategorii na stronach OWASP, numery ASVS z plików wersji 5.0.0 w repozytorium projektu (OWASP ASVS 5.0.0, GitHub). Myślnik oznacza brak odpowiednika w danym standardzie, na przykład kopie zapasowe nie występują w OWASP Top 10. Pod tabelą każdej grupy znajdziesz odnośniki do poradników OWASP, a w tekście to, o co warto zapytać wykonawcę.

Poziomy ASVS

ASVS ma trzy poziomy. Poziom 1 to minimalny zestaw wymagań dla organizacji, które zaczynają porządkować bezpieczeństwo. Poziom 2 OWASP określa jako cel dla większości aplikacji i obejmuje wymagania z poziomów 1 i 2. Poziom 3 jest przeznaczony dla aplikacji, które muszą wykazać najwyższy poziom zabezpieczeń, na przykład dla bardzo wrażliwych danych (ASVS 5.0.0, rozdział „What is the ASVS”). W tabelach przy numerze stoi oznaczenie poziomu, np. 6.2.1 (L1).

Zgodność z ASVS i certyfikat

OWASP nie certyfikuje oprogramowania ani wykonawców pod kątem ASVS i zaleca ostrożność wobec ofert powołujących się na taki certyfikat. Raport z weryfikacji powinien podawać zakres, docelowy poziom i listę sprawdzonych wymagań (ASVS 5.0.0, rozdział o ocenie i certyfikacji). Dlatego używam sformułowania „odnosi się do”: wskazuję, który standard dotyka danego zabezpieczenia, i nie deklaruję zgodności. Raport z naszych prac jest raportem z ustaleniami.

Jak zabezpieczyć logowanie i sesje użytkowników?

Logowanie to pierwsza rzecz, którą atakujący sprawdza. OWASP zebrał błędy tej grupy w kategorii A07:2025: brak ochrony przed automatycznymi atakami na hasła, domyślne i słabe hasła, słabe odzyskiwanie konta, brak MFA oraz sesje, które nie wygasają po wylogowaniu lub bezczynności (OWASP, A07:2025).

Poradniki OWASP (Cheat Sheet Series): Authentication, Session Management, Password Storage.

A1. Polityka haseł

Zapytaj, jak długie hasło wymusza aplikacja, czy porównuje nowe hasła z listą popularnych i wyciekłych oraz czy nie każe ich zmieniać co kilka tygodni. ASVS wymaga co najmniej 8 znaków i zaleca 15 (6.2.1), a OWASP radzi sprawdzać hasła z listą wycieków i nie wymuszać okresowej zmiany, zgodnie z NIST SP 800-63B (OWASP, A07:2025). Wersja 800-63B-4 ukazała się w lipcu 2025 r. (NIST).

A2. Uwierzytelnianie wieloskładnikowe (MFA)

W ASVS 5.0.0 poziom 2 zakłada wymuszenie MFA (6.3.3), a poziom 3 wymaga składnika sprzętowego odpornego na wyłudzanie, jak klucz FIDO. NIS2 wymienia MFA w art. 21 ust. 2 lit. j. Z mojego doświadczenia klienci najczęściej nie wdrażają dwuetapowego logowania (MFA) w aplikacjach biznesowych ani tam, gdzie są dane wrażliwe.

Porada 2:

Zacznij od MFA dla kont administratorów i dla każdego konta, które widzi dane osobowe lub finansowe. Dla zwykłych użytkowników możesz wprowadzić je później, ale zaplanuj miejsce na nie w pierwszej wersji aplikacji. Łatwiej uwzględnić MFA w projekcie niż dobudowywać je do gotowego systemu.

A3. Ochrona przed brute force i credential stuffing

Credential stuffing to wypróbowywanie loginów i haseł z cudzych wycieków. Obrona to limity prób logowania i opóźnienia, które jednocześnie nie pozwalają zablokować cudzego konta (ASVS 6.1.1 i 6.3.1). Z mojego doświadczenia w aplikacjach często brakuje limitów prób logowania. Jeśli zamawiasz aplikację, wpisz je do wymagań.

A4. Bezpieczne sesje

Po zalogowaniu aplikacja wystawia identyfikator sesji. Zapytaj, czy wygasa po bezczynności, czy wylogowanie naprawdę go unieważnia i czy administrator może zakończyć sesję użytkownika. Dla tokenów referencyjnych, czyli identyfikatorów sesji przechowywanych na serwerze, ASVS 7.2.3 wymaga losowości z generatora kryptograficznego i co najmniej 128 bitów entropii. Czasy wygasania ustala się z użytkownikami, a ASVS wymaga, żeby były udokumentowane (7.1.1).

A5. Odzyskiwanie konta

Reset hasła bywa obejściem MFA, dlatego ASVS 6.4.3 wymaga, żeby proces resetu go nie omijał. OWASP zaleca też jednakowe komunikaty dla każdego wyniku logowania, aby aplikacja nie zdradzała, czy konto istnieje.

Zdarza się, że klienci udostępniają jedno konto (login i hasło) kilku pracownikom, żeby nie płacić w SaaS za dodatkowego użytkownika. Przy wspólnym koncie nie da się ustalić, kto co zrobił, więc logi z dalszych sekcji tracą wartość. Jeśli oszczędzasz na licencjach, policz to z kosztem jednego incydentu.

Jak ustawić kontrolę dostępu w aplikacji webowej?

Kontrola dostępu decyduje, kto może zobaczyć lub zmienić jakie dane. W OWASP Top 10:2025 jest na pierwszym miejscu (A01). Według opisu kategorii wszystkie testowane aplikacje miały jakąś formę tego błędu, przy średnim współczynniku występowania 3,74% (maksymalnie 20,15%) (OWASP, A01:2025). Średnia dotyczy próby aplikacji przekazanych OWASP. Do typowych błędów OWASP zalicza dostęp domyślnie dozwolony, obejście kontroli przez zmianę adresu lub zapytania API, odczyt cudzych rekordów po zmianie identyfikatora i niezabezpieczone metody POST, PUT i DELETE.

Poradniki OWASP (Cheat Sheet Series): Authorization, IDOR Prevention.

B1. Autoryzacja funkcji

Funkcje, na przykład eksport faktur albo usunięcie użytkownika, mają być dostępne tylko dla ról z wyraźnym uprawnieniem, a reguły mają być udokumentowane (ASVS 8.2.1 i 8.1.1). W przejmowanych projektach najczęściej widzę brak kontroli nad dostępami dla różnych ról: nigdzie nie ma informacji, kto do czego ma dostęp, więc nie da się tego zweryfikować. Dlatego przy zamawianiu aplikacji żądaj macierzy ról i uprawnień jako dokumentu. OWASP zaleca domyślne odmawianie dostępu, reguły zapisane raz w zaufanym kodzie po stronie serwera (bo kontrole po stronie klienta można obejść) oraz testy kontroli dostępu w zestawie testów. W RODO ten element odnosi się do zdolności zapewnienia poufności i integralności (art. 32 ust. 1 lit. b).

B2. Autoryzacja obiektów (IDOR)

To błąd, w którym zmiana identyfikatora w adresie lub zapytaniu API pokazuje cudze zamówienie lub fakturę. ASVS 8.2.2 wymaga uprawnień do konkretnych rekordów, a lista API Top 10 nazywa to API1. W testach aplikacji z kontami klientów to jedno z podstawowych sprawdzeń, bo skutki są natychmiastowe.

B3. Najmniejsze uprawnienia kont i usług

Każdy komponent i konto powinny mieć tylko uprawnienia, których potrzebują (ASVS 13.2.2 i 13.3.2). Brakuje też dodatkowych zabezpieczeń kont admina z najwyższymi uprawnieniami. Takie konto warto chronić mocniej niż zwykłe: MFA, osobne konto do pracy administracyjnej, rejestr jego działań i ograniczenie do niezbędnej liczby osób.

B4. Dostęp do kodu i środowisk

Kod, serwery buildów i środowiska wdrożeniowe są celem tak samo jak sama aplikacja. SSDF (PS.1) każe przechowywać kod z najmniejszymi uprawnieniami, a OWASP w A03 zaleca MFA i najmniejsze uprawnienia w repozytoriach, na stacjach deweloperów i w systemach CI/CD. Zapytaj wykonawcę, kto ma dostęp do repozytorium i czy odbierasz te dostępy, gdy ktoś odchodzi z projektu.

Jak chronić aplikację przed wstrzyknięciami i błędnymi danymi?

Wstrzyknięcie występuje wtedy, gdy dane od użytkownika trafiają do interpretera (bazy danych, przeglądarki, systemu operacyjnego) i zostają potraktowane jako polecenie. W Top 10:2025 to A05. Siedem elementów tej grupy łączy jedna zasada: żadnym danym z zewnątrz nie ufaj bez sprawdzenia.

Jak działają SQL injection, XSS i CSRF?

SQL injection polega na tym, że tekst wpisany przez atakującego trafia do zapytania do bazy i zmienia jego znaczenie. OWASP opisuje to w A05 jako dane doklejone do zapytania, które zmieniają jego strukturę (OWASP, A05:2025). Skutkiem może być odczyt, zmiana lub usunięcie danych, do których atakujący nie miał mieć dostępu. Obronę opisuje SQL Injection Prevention Cheat Sheet.

XSS (cross-site scripting) polega na tym, że cudzy skrypt wykonuje się w przeglądarce Twojego użytkownika, bo aplikacja wyświetliła niezakodowaną treść. Skutkiem może być przejęcie sesji albo podmiana treści strony. Obronę opisuje XSS Prevention Cheat Sheet.

CSRF (cross-site request forgery) polega na tym, że zalogowany użytkownik wchodzi na cudzą stronę, a ta wysyła w jego imieniu żądanie do Twojej aplikacji. Skutkiem może być zmiana danych lub zlecenie operacji w jego imieniu. Obronę opisuje CSRF Prevention Cheat Sheet. W checkliście przed pierwszymi dwoma chronią elementy C1 i C2, a przed CSRF element E3.

Poradniki OWASP (Cheat Sheet Series): SQL Injection Prevention, Query Parameterization, XSS Prevention, Input Validation, Error Handling, File Upload, REST Security.

C1-C2. Zapytania parametryzowane i kodowanie wyjścia

Zapytania do bazy mają używać parametrów, ORM albo równoważnej ochrony (ASVS 1.2.4). Parametryzacja nie obejmuje nazw tabel i kolumn, na przykład w klauzuli ORDER BY, więc takie elementy trzeba ograniczać listą dozwolonych wartości. OWASP w A05 dodaje, że procedury składowane też bywają podatne, jeśli sklejają dane wejściowe. Przeciw XSS służy kodowanie danych odpowiednio do miejsca, w którym trafiają (HTML, adres URL, JavaScript), oraz sanityzacja treści z edytorów WYSIWYG sprawdzoną biblioteką (ASVS 1.2.1-1.2.3 i 1.3.1).

C3. Walidacja po stronie serwera

Walidacja w przeglądarce poprawia wygodę użytkownika, ale chroni dopiero kontrola na serwerze (ASVS 2.2.2). W przejmowanych projektach najczęściej widzę brak walidacji po frontendzie i backendzie. OWASP zastrzega, że sama walidacja nie jest pełną obroną przed wstrzyknięciami.

C4. Logika biznesowa i limity wywołań

Nie każdy błąd to wstrzyknięcie. Czasem da się pominąć krok procesu, na przykład wykonać zamówienie bez płatności (ASVS 2.3.1), albo wywołać funkcję tysiące razy i wyczerpać limity lub budżet (2.4.1). W Top 10 jest to A06 (niebezpieczny projekt), a w API Top 10 API6. Według OWASP Web Security Testing Guide (wersja 4.2) tego typu podatności nie wykrywa skaner podatności, a ich znalezienie zależy od umiejętności i kreatywności testera (OWASP WSTG 4.2, Business Logic Testing). O ryzykach przy płatnościach i uwierzytelnianiu pisałem w artykule o funkcjach, których nie warto budować z AI bez wiedzy technicznej.

C5. Obsługa wyjątków i błędów

A10:2025 to nowa kategoria: błąd nieobsłużony tam, gdzie wystąpił, oraz awaria, po której system przepuszcza żądania zamiast je zatrzymać. OWASP zaleca globalny handler jako siatkę bezpieczeństwa i wycofanie całej transakcji, gdy w jej trakcie wystąpi błąd (OWASP, A10:2025). Użytkownik ma widzieć ogólny komunikat bez śladu stosu (ASVS 16.5.1).

C6-C7. Upload plików i API

Plik od użytkownika może być plikiem wykonywalnym, bombą dekompresyjną albo nośnikiem złośliwej treści, więc zapytaj o limity rozmiaru, sprawdzanie typu i zawartości oraz o to, czy wgrany plik nie może zostać uruchomiony jako kod (ASVS 5.2.1, 5.2.2, 5.3.1). API to drzwi dla aplikacji mobilnych i integracji, więc dziedziczy wszystkie grupy z tej checklisty. Dla GraphQL ASVS wymaga limitów głębokości i kosztu zapytań oraz wyłączonej introspekcji w produkcji (4.3.1 i 4.3.2), a dla WebSocket szyfrowanego połączenia i sprawdzania nagłówka Origin (4.4.1 i 4.4.2).

Jak szyfrować dane i przechowywać sekrety?

Szyfrowanie chroni dane w drodze i w spoczynku. RODO w art. 32 ust. 1 lit. a wymienia je wprost jako przykład środka, a NIS2 w art. 21 ust. 2 lit. h wymaga polityk dotyczących kryptografii. W Top 10:2025 to A04, z zaleceniami: klasyfikacja danych, szyfrowanie wszystkich danych wrażliwych w spoczynku, TLS 1.2 lub nowszy z HSTS, hashowanie haseł funkcjami Argon2, scrypt, yescrypt lub PBKDF2-HMAC-SHA-512 i przygotowanie systemów wysokiego ryzyka na kryptografię postkwantową do końca 2030 r. (OWASP, A04:2025).

Poradniki OWASP (Cheat Sheet Series): Transport Layer Security, Cryptographic Storage, Secrets Management.

D1. TLS i HSTS

Cały ruch ma iść przez szyfrowane połączenie, także między aplikacją a bazą i usługami wewnętrznymi. ASVS wymaga zalecanych wersji TLS (1.2 i 1.3), publicznie zaufanych certyfikatów i braku możliwości cofnięcia się do połączenia nieszyfrowanego (12.1.1, 12.2.1, 12.2.2), a na poziomie 2 także szyfrowania połączeń wewnętrznych (12.3.1-12.3.4). Nagłówek HSTS (3.4.1) nakazuje przeglądarce używać wyłącznie HTTPS.

D2. Szyfry i hashowanie

Hasła przechowuje się jako wynik funkcji hashującej przeznaczonej do haseł (ASVS 11.4.2), a szyfry mają być zatwierdzone, na przykład AES w trybie GCM (11.3.2). Funkcje takie jak MD5 są zabronione (11.4.1). ASVS 11.2.1 wymaga sprawdzonych implementacji kryptografii, więc własny algorytm szyfrowania w ofercie wykonawcy to sygnał do pytań.

D3. Klucze i sekrety

Hasła do bazy, klucze API i certyfikaty nie powinny leżeć w kodzie. ASVS 13.3.1 wymaga menedżera sekretów i trzymania ich poza kodem źródłowym i artefaktami budowania, a 11.1.1 i 11.1.2 udokumentowanej polityki zarządzania kluczami oraz ich inwentarza. OWASP w A02 wskazuje krótkotrwałe poświadczenia zamiast zaszytych kluczy. Do wykrywania haseł i kluczy w repozytorium służą skanery sekretów, na przykład Gitleaks.

D4. Klasyfikacja, minimalizacja i retencja danych

Najbezpieczniejsze dane to te, których nie zbierasz. ASVS wymaga zidentyfikowania danych wrażliwych i przypisania im poziomów ochrony (14.1.1), zwracania minimalnego zakresu (14.2.6), usuwania nieaktualnych danych (14.2.7) i nietrzymania wrażliwych informacji w pamięci przeglądarki (14.3.3). W RODO odnosi się do tego pseudonimizacja z art. 32 ust. 1 lit. a i ocena ryzyka z ust. 2. W projekcie CRM dla brokera ubezpieczeniowego pracowaliśmy z zaszyfrowanymi danymi.

Jakie ustawienia i nagłówki wzmacniają aplikację w przeglądarce?

Błędna konfiguracja (A02:2025) jest drugą kategorią Top 10. OWASP podaje, że wszystkie testowane aplikacje miały jej jakąś formę, przy średnim współczynniku występowania 3,00% (maksymalnie 27,70%) (OWASP, A02:2025). Zalecenie OWASP: powtarzalny, zautomatyzowany proces hardeningu, jednakowe środowiska deweloperskie, testowe i produkcyjne z różnymi poświadczeniami oraz weryfikacja konfiguracji, a jeśli nie jest zautomatyzowana, to ręcznie co najmniej raz w roku.

Poradniki OWASP (Cheat Sheet Series): HTTP Headers, Content Security Policy, CSRF Prevention, SSRF Prevention.

E1. Hardening i ustawienia domyślne

Na produkcji wyłączamy tryb debugowania, listę plików w katalogach, publiczną dokumentację i endpointy monitoringu oraz nie zostawiamy folderów typu .git (ASVS 13.4.1-13.4.5), a domyślne hasła usług są niedozwolone (13.2.3). SSDF (PW.9) opisuje to jako bezpieczne ustawienia domyślne w dostarczanym oprogramowaniu.

E2. Nagłówki i ciasteczka

Przeglądarka ma własne mechanizmy obrony, ale aplikacja musi je włączyć. Chodzi o nagłówek Content-Security-Policy ograniczający źródła skryptów (ASVS 3.4.3), nosniff (3.4.4), dyrektywę frame-ancestors przeciw osadzaniu aplikacji w cudzych ramkach (3.4.6) oraz atrybuty ciasteczek Secure, SameSite i HttpOnly (3.3.1, 3.3.2, 3.3.4). Sprawdzenie ich obecności to zadanie dla audytora lub skanera.

E3. CSRF i CORS

Obrona przed CSRF to tokeny anty-CSRF lub równoważne mechanizmy (ASVS 3.5.1) i użycie metod innych niż GET dla funkcji wrażliwych (3.5.3). Dla CORS aplikacja ma używać stałej wartości Access-Control-Allow-Origin albo listy zaufanych źródeł (3.4.2).

E4. SSRF i ruch wychodzący

SSRF polega na tym, że atakujący nakłania serwer do wysłania żądania do adresu wewnętrznego. W Top 10:2025 został włączony do A01, a w API Top 10 to API7. ASVS 13.2.4 wymaga listy dozwolonych zewnętrznych zasobów, z którymi aplikacja może się komunikować.

E5. Rozdzielenie środowisk

Środowiska testowe, stagingowe i produkcyjne powinny mieć osobne poświadczenia, a na produkcji nie ma kodu testowego ani przykładów (ASVS 15.2.3). Prawdziwe dane osobowe w środowisku testowym zwiększają ryzyko, więc zanonimizuj je lub zastąp danymi testowymi.

Jak kontrolować zależności i łańcuch dostaw?

Nowoczesna aplikacja to w większości cudzy kod: biblioteki, frameworki, narzędzia budowania. OWASP rozszerzył dawną kategorię przestarzałych komponentów do A03:2025 (awarie łańcucha dostaw oprogramowania) i podaje, że ma ona najwyższy średni współczynnik występowania w przekazanych danych: 5,19% według opisu kategorii (tabela wyników na tej samej stronie podaje 5,72%). Wymienia w niej m.in. Log4Shell i kompromitację SolarWinds (OWASP, A03:2025). Wartość dotyczy próby danych OWASP i nie mówi o szansie ataku w konkretnej firmie. Pokrewna kategoria A08 (integralność oprogramowania lub danych) ma średni współczynnik 2,75% (OWASP, A08:2025).

Poradniki OWASP (Cheat Sheet Series): Software Supply Chain Security, Vulnerable Dependency Management.

F1. Inwentarz zależności (SBOM)

SBOM (Software Bill of Materials) to lista wszystkich bibliotek, także pośrednich, z których składa się aplikacja. ASVS 15.1.2 wymaga takiego inwentarza, a OWASP w A03 zaleca generowanie centralnego SBOM, usuwanie nieużywanych zależności i śledzenie podatności w CVE, NVD i OSV. Bez listy nie dowiesz się, czy dotyczy Cię nowo ogłoszona luka. Popularne formaty SBOM to CycloneDX i SPDX.

F2. Aktualizacje z terminami

ASVS wymaga udokumentowanych, opartych na ryzyku terminów naprawy podatnych komponentów (15.1.1) i aplikacji bez komponentów po tych terminach (15.2.1). W każdym przejmowanym projekcie znajduję nieaktualne biblioteki. Dla Ciebie oznacza to zapis w umowie lub w zasadach utrzymania: w ciągu ilu dni od ogłoszenia poważnej luki wykonawca ją łata. Skutki zaniedbań opisuję w artykule o długu technologicznym, a zakres prac utrzymaniowych opisuje usługa utrzymania aplikacji i systemu.

F3. Pipeline CI/CD i integralność wydań

Ścieżka od kodu do produkcji powinna być chroniona i śledzona. OWASP w A03 zaleca podpisy, pochodzenie artefaktów, przegląd zmian przez pull requesty i MFA w systemach CI/CD, a w A08 podpisy cyfrowe, zaufane repozytoria i rozdzielenie uprawnień w potoku. W przejmowanych projektach najczęściej widzę brak procesu wdrożenia zmian, więc przy zamawianiu aplikacji zapytaj, jak wygląda droga zmiany od zgłoszenia do produkcji.

F4. Dostawcy i podwykonawcy

Zewnętrzne usługi (płatności, e-mail, analityka, wykonawca, a nawet hosting) też są częścią łańcucha dostaw. NIS2 w art. 21 ust. 2 lit. d i ust. 3 każe uwzględniać podatności konkretnego dostawcy oraz jakość jego praktyk, w tym procedur bezpiecznego wytwarzania. Zapytaj swojego wykonawcę, jakie ma zasady, i sprawdź, czy umowa to opisuje. O klauzulach poufności i zapisach o kodzie generowanym przez AI piszę w artykule o tym, co powinna zawierać umowa z software house, a kryteria wyboru wykonawcy opisuję w tekście jak wybrać software house.

Co logować i jak reagować na incydenty?

Brak logów i alarmów sprawia, że atak może trwać niezauważony. OWASP opisuje to w A09:2025 jako luki w logowaniu, monitorowaniu i alarmowaniu, które utrudniają wykrycie naruszenia i szybką reakcję. Kategoria jest trudna do testowania i mało widoczna w danych CVE (OWASP, A09:2025). Za objawy problemu OWASP uznaje m.in. brak logów logowań i wartościowych transakcji, logi tylko lokalne i niechronione przed modyfikacją, brak progów alarmowych oraz brak playbooków reakcji.

Poradniki OWASP (Cheat Sheet Series): Logging, Logging Vocabulary.

G1. Logowanie zdarzeń bezpieczeństwa

ASVS wymaga rejestrowania prób uwierzytelniania, odmów dostępu, prób obejścia zabezpieczeń i nieoczekiwanych błędów (16.3.1-16.3.4). W praktyce: kto, kiedy, skąd i co próbował zrobić. Logi muszą być używane, więc ktoś musi je przeglądać albo mieć skonfigurowane alerty. Z mojego doświadczenia logi często są dostępne tylko dla osób technicznych na serwerze (VPS lub serwer dedykowany) i nie są widoczne w panelu administracyjnym aplikacji. Rekomenduję, żeby logi zdarzeń bezpieczeństwa były dostępne także dla uprawnionej osoby po stronie biznesu.

G2. Ochrona logów

Logi chronimy przed edycją i przed wstrzyknięciem, przekazujemy je do osobnego systemu, a danych wrażliwych nie zapisujemy lub tylko w postaci zahaszowanej albo zamaskowanej (ASVS 16.2.5, 16.4.1-16.4.3). OWASP w A09 dodaje ślady audytowe z kontrolą integralności, na przykład tabele tylko do dopisywania. Log pełen numerów PESEL lub haseł sam staje się źródłem wycieku.

G3. Monitoring i alerty

OWASP zaleca scenariusze alarmowe z instrukcjami reakcji, a także pułapki w postaci fałszywych rekordów (honeytokens), do których zwykły proces biznesowy nigdy nie sięga, więc każdy dostęp jest wyraźnym sygnałem. Jako oznakę słabości wymienia sytuację, w której testy penetracyjne i skanery DAST nie wywołują żadnych alertów.

G4. Plan reakcji na incydenty

Plan to krótki dokument: kto decyduje, kto komunikuje się z klientami i regulatorem, jak odcinamy system, skąd bierzemy ostatnią dobrą kopię. Przy danych osobowych liczy się czas, bo art. 33 ust. 1 RODO wymaga zgłoszenia naruszenia organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by powodowało ryzyko naruszenia praw lub wolności osób. NIS2 (lit. b) wymienia obsługę incydentów jako środek zarządzania ryzykiem. OWASP w A09 wskazuje jako wzorzec plan reakcji i odtwarzania według NIST SP 800-61r2.

G5. Zgłaszanie podatności

Ktoś z zewnątrz może znaleźć błąd w Twojej aplikacji. Warto mieć stronę lub adres, pod którym przyjmiesz zgłoszenie. SSDF (RV.1) wymienia politykę ujawniania podatności, a NIS2 w art. 21 ust. 2 lit. e mówi o obsłudze i ujawnianiu podatności.

Jak zapewnić kopie zapasowe i odporność na awarie?

Kopie zapasowe nie występują w OWASP Top 10, ale RODO (art. 32 ust. 1 lit. c) wymaga zdolności przywrócenia dostępu do danych w odpowiednim czasie, NIS2 (art. 21 ust. 2 lit. c) wymienia ciągłość działania, w tym zarządzanie kopiami zapasowymi, a ISO 27001 ma kontrolę A.8.13. To przykład, że lista ryzyk aplikacyjnych nie pokrywa całej odpowiedzialności.

H1. Kopie zapasowe i test odtwarzania

Z mojego doświadczenia najczęściej brakuje kopii zapasowych z testami odtwarzania. Klienci najczęściej nie chcą płacić za tę usługę i nie biorą ryzyka pod uwagę. Kopia, której nikt nie odtworzył, pozostaje założeniem. Ustal trzy rzeczy: co jest kopiowane (baza danych i pliki użytkowników), jak często oraz gdzie leży kopia (inny serwer lub inna lokalizacja niż produkcja). Następnie zamów próbne odtworzenie przynajmniej raz w roku i po większych zmianach.

Porada 3:

Dopisz do umowy utrzymania jedno zdanie: wykonawca raz w roku odtwarza kopię na osobnym środowisku i przekazuje Ci wynik. Wtedy o pustej lub uszkodzonej kopii dowiadujesz się podczas testu, a nie podczas awarii.

H2. Dostępność i odporność na przeciążenie

Dostępność to także bezpieczeństwo. ASVS wymaga obrony przed utratą dostępności przez funkcje zasobożerne (15.2.2), a lista API Top 10 ma API4 (nieograniczone zużycie zasobów). W RODO art. 32 ust. 1 lit. b mówi o odporności systemów. Zagadnienia skalowania opisuję szerzej w artykule bazy wiedzy o skalowalności aplikacji webowej.

Jak wbudować bezpieczeństwo w proces wytwarzania i testy?

Zabezpieczeń nie da się dodać na końcu projektu jak lakieru. Dotyczy to procesu, w którym aplikacja powstaje. SSDF opisuje go w czterech grupach praktyk, a w Top 10 odpowiada za to A06 (niebezpieczny projekt). W przejmowanych projektach najczęściej widzę brak standardów architektury i wzorców, przez co wydłuża się czas każdego nowego zadania, bo nie wiadomo, co gdzie jest.

Jaki zestaw zabezpieczeń rekomenduję dla nowej aplikacji?

Poradniki OWASP (Cheat Sheet Series): Threat Modeling.

I1. Wymagania i modelowanie zagrożeń

Zanim ktoś napisze kod, warto ustalić, co chronimy i przed kim. SSDF (PO.1) każe zdefiniować wymagania bezpieczeństwa, PW.1 zaleca modelowanie ryzyka przy projektowaniu, a PW.2 niezależny przegląd projektu. OWASP w A06 zaleca modelowanie zagrożeń dla uwierzytelniania, kontroli dostępu i logiki biznesowej oraz testy nadużyć (misuse cases), które potwierdzają, że krytyczne przepływy wytrzymują zagrożenia z modelu.

I2. Bezpieczne kodowanie i code review

Zespół stosuje ustalone zasady kodowania (SSDF PW.5), a kod przechodzi przegląd przez drugą osobę lub narzędzie (PW.7). Dotyczy to także kodu generowanego przez AI. Różnice w podejściu opisuję w artykule aplikacja zaprogramowana przez AI vs. przez software house.

I3. Testy automatyczne (SAST, DAST, SCA)

SAST analizuje kod bez uruchamiania, DAST sprawdza uruchomioną aplikację, a SCA bada zależności. Dobrze, gdy skany uruchamiają się w pipeline przy każdej zmianie. Poniżej popularne narzędzia z każdej kategorii. To przykłady z dokumentacji ich autorów i nie jest to lista narzędzi używanych przez konkretnego wykonawcę.

I4. Testy penetracyjne

Test penetracyjny to ręczne sprawdzenie, czy luki da się wykorzystać. Odnosi się do niego RODO (art. 32 ust. 1 lit. d, regularne testowanie skuteczności środków), NIS2 (lit. f), CIS (kontrola 18) i ISO 27001 (A.8.29). Szczegóły, kiedy go zamawiać i jak wybrać wykonawcę, opisałem w artykule o testach penetracyjnych.

I5. Szkolenie zespołu

SSDF (PO.2) przewiduje szkolenia z bezpiecznego wytwarzania dopasowane do ról, a NIS2 w art. 21 ust. 2 lit. g podstawową higienę cybernetyczną i szkolenia. Zapytaj wykonawcę, jak jego programiści uczą się bezpiecznych praktyk.

Które aplikacje potrzebują dodatkowych zabezpieczeń?

Dodatkowych zabezpieczeń wymagają aplikacje, które przetwarzają dane szczególnie chronione albo działają w instytucjach publicznych, bo skutki wycieku lub awarii są tam większe, a przepisy stawiają konkretne wymagania. Poniżej trzy branże. W każdej potrzebne są te same cztery elementy: konta, dostęp, logi i kopie zapasowe, a listy pokazują, co w danej branży dochodzi.

SaaS dla gabinetów stomatologicznych i innych placówek medycznych

System, w którym gabinet prowadzi kartotekę pacjentów i historię leczenia, zwykle przetwarza dane dotyczące zdrowia. RODO definiuje je w art. 4 pkt 15 jako dane osobowe o zdrowiu fizycznym lub psychicznym, ujawniające informacje o stanie zdrowia, w tym o usługach opieki zdrowotnej. Motyw 35 dodaje, że należą do nich informacje zebrane przy rejestracji na usługi zdrowotne oraz dane o chorobie, historii medycznej i leczeniu, niezależnie od źródła (RODO, art. 4 pkt 15 i motyw 35, EUR-Lex).

Art. 9 ust. 1 RODO zalicza dane dotyczące zdrowia do szczególnych kategorii i co do zasady zakazuje ich przetwarzania. Zakaz nie obowiązuje m.in. przy wyraźnej zgodzie (ust. 2 lit. a) oraz w celu opieki zdrowotnej, na podstawie prawa lub umowy z pracownikiem ochrony zdrowia, gdy dane przetwarza osoba objęta tajemnicą zawodową (ust. 2 lit. h i ust. 3). Podstawa prawna przetwarzania to sprawa dla prawnika. Dla Ciebie jako właściciela systemu wniosek jest praktyczny: bezpieczeństwo musi odpowiadać ryzyku, które art. 32 RODO nakazuje ocenić, a ryzyko dla danych o zdrowiu jest wysokie.

Dochodzą przepisy sektorowe. Rozporządzenie Ministra Zdrowia z 6 kwietnia 2020 r. w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania reguluje sposób prowadzenia dokumentacji medycznej, także w systemach informatycznych. Obecny tekst jednolity to obwieszczenie Ministra Zdrowia z 4 września 2026 r. (Dz.U. 2026 poz. 1391, ogłoszone 23 października 2026 r.) (Dziennik Ustaw, ELI). Wymagania dla konkretnego systemu zawsze sprawdzaj w aktualnym tekście jednolitym.

Realizowaliśmy projekty z branży medycznej, ale umowy NDA nie pozwalają mi ich opisać. Mogę za to wskazać, co w takim systemie sprawdzałbym w tej kolejności: najpierw konta imienne, role i MFA, bo od nich zależy, czy wiadomo, kto wpisał dane; potem izolację danych między pacjentami i między gabinetami; następnie szyfrowanie i dostęp do dokumentacji; potem logi dostępu do kart pacjentów; na końcu kopie zapasowe z testem odtwarzania i plan reakcji na incydent.

Portale instytucji państwowych

Portal publiczny nie musi przetwarzać danych szczególnych kategorii, żeby podlegać wymaganiom, bo te wynikają z tego, kto jest właścicielem systemu. Rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2024 poz. 773) obowiązuje od 23 maja 2024 r. (Dziennik Ustaw, ELI).

Zgodnie z § 19 ust. 1 podmiot realizujący zadania publiczne ustanawia i utrzymuje system zarządzania bezpieczeństwem informacji. Ust. 2 wymienia m.in. okresowe analizy ryzyka utraty integralności, dostępności lub poufności, ochronę informacji przed nieuprawnionym dostępem, zapisy o bezpieczeństwie w umowach serwisowych ze stronami trzecimi, odpowiedni poziom bezpieczeństwa systemów teleinformatycznych oraz wewnętrzny audyt bezpieczeństwa informacji nie rzadziej niż raz w roku. § 20 wymaga dzienników systemów, w których rejestruje się m.in. działania z uprawnieniami administracyjnymi i dostęp do danych chronionych prawem. Informacje w dziennikach przechowuje się przez okres wskazany w przepisach odrębnych, a w przypadku ich braku przez dwa lata (Dz.U. 2024 poz. 773, tekst, ISAP).

Jedną z naszych realizacji jest obsługa portalu instytucji państwowej (bazy poloników). Po przejęciu projektu od poprzedniego wykonawcy wykonaliśmy audyt bezpieczeństwa, wdrożyliśmy repozytorium GitLab na serwerze VPS oraz automatyczne kopie zapasowe bazy danych i plików na serwerze backupowym, a później wykonaliśmy pełny skan kodu. Opis jest w case study obsługa portalu instytucji państwowej. W tej realizacji najpierw był audyt, infrastruktura i kopie, a dopiero potem skan i refaktoryzacja kodu.

Aplikacje i systemy fitness

Czy dane z aplikacji fitness są danymi o zdrowiu, zależy od tego, co aplikacja zbiera i do czego to wykorzystuje. Definicja z art. 4 pkt 15 RODO i motyw 35 są szerokie: obejmują informacje o stanie zdrowia, w tym o stanie fizjologicznym, niezależnie od tego, czy pochodzą od lekarza, czy z urządzenia medycznego. Aplikacja, która zapisuje wyłącznie rodzaj treningu, może znaleźć się poza tą kategorią. Aplikacja, która przechowuje informacje o chorobach, historii medycznej lub leczeniu, mieści się w niej wprost.

Wskazówkę daje dokument Grupy Roboczej Art. 29 (poprzedniczki Europejskiej Rady Ochrony Danych) z 2015 r., napisany jeszcze przed RODO. Według omówienia kancelarii Covington wyróżnia trzy sytuacje: dane wyraźnie medyczne, surowe dane z czujników, z których można wnioskować o stanie zdrowia lub jego ryzyku (samodzielnie lub w połączeniu z innymi danymi, także śledzone w czasie), oraz wnioski o zdrowiu wyciągane z danych, niezależnie od tego, czy są trafne (Covington, Inside Privacy, 2015; dokument źródłowy: Grupa Robocza Art. 29, załącznik do pisma z 5.02.2015). To wskazówka interpretacyjna sprzed RODO i nie jest przepisem, więc decyzję w konkretnym projekcie najlepiej skonsultować z prawnikiem lub inspektorem ochrony danych.

W projekcie platformy streamingowej dla startupu fitness z USA wdrożyliśmy wybór danych, zgody i szyfrowanie. Użytkownikami były często kobiety, które dodawały dane zdrowotne związane z okresem po ciąży. Czy takie dane są danymi o zdrowiu w rozumieniu RODO, ocenia się według kryteriów z art. 4 pkt 15 RODO i motywu 35: co aplikacja zbiera i do czego to wykorzystuje.

Moja rada: jeśli już na etapie zakresu wiesz, że aplikacja będzie zbierać dane, z których da się wnioskować o zdrowiu, projektuj ją tak, jakby były danymi szczególnej kategorii. Zaplanowanie zabezpieczeń na początku jest łatwiejsze niż dobudowywanie ich do gotowego systemu. Jedną z podstaw, które RODO dopuszcza dla takich danych, jest wyraźna zgoda (art. 9 ust. 2 lit. a).

Od czego zacząć, gdy firma nie ma zasobów na wszystko?

Nie musisz wdrożyć wszystkiego naraz. Poniżej kolejność poprawek, jaką rekomenduję, gdy porządkujesz istniejącą aplikację. Oparłem ją na pozycjach OWASP Top 10:2025 (A01 i A07 stoją na początku listy), na wymaganiach poziomu 1 w ASVS i na wymaganiach RODO dotyczących odtwarzania danych.

W ASVS odpowiada temu ścieżka od poziomu 1 do poziomu 2. Zacznij od wymagań oznaczonych L1, bo OWASP określa je jako minimum, a po ich wdrożeniu przejdź do L2. Z mojego doświadczenia często brakuje trzech rzeczy z tej listy: MFA, kopii zapasowych z testami odtwarzania i dodatkowych zabezpieczeń kont administratora z najwyższymi uprawnieniami. Zacznij więc od nich.

Jakie błędy poprzednich wykonawców są typowe w przejmowanych projektach?

Jeśli przejmujesz aplikację od innego wykonawcy albo zamierzasz to zrobić, sprawdź, czy nie ma w niej typowych błędów. W przejmowanych projektach pojawiają się: brak dokumentacji, brak środowiska testowego, dostępy zostawione byłym programistom, brak repozytorium kodu, hasła i klucze w repozytorium, jedno wspólne środowisko do rozwoju i produkcji, brak aktualizacji, brak kopii zapasowych, brak podziału ról oraz brak przeglądu kodu. Każdy z nich odpowiada jednemu lub kilku elementom tej checklisty, więc możesz użyć jej jako listy kontrolnej przy odbiorze projektu.

O co zapytać wykonawcę?

Porada 4:

Zapisz odpowiedzi w umowie lub załączniku do niej. Odpowiedź ustna na spotkaniu jest za miesiąc trudna do odtworzenia.

Kiedy sama checklista nie wystarczy?

Checklista porządkuje rozmowę z wykonawcą, ale opiera się na jego deklaracjach. Żeby wiedzieć, jak jest naprawdę, potrzebujesz sprawdzenia kodu, konfiguracji lub zachowania aplikacji pod atakiem. Rodzaj sprawdzenia dobiera się do pytania: audyt kodu pokazuje błędy w logice i architekturze, audyt bezpieczeństwa porównuje aplikację z wybranym zestawem wymagań, a test penetracyjny ręcznie próbuje te błędy wykorzystać. Jeśli dopiero planujesz budowę, zabezpieczenia wchodzą do zakresu prac nad aplikacjami webowymi już na etapie projektu.

Wynik testu pokazuje stan z dnia sprawdzenia. Brytyjskie NCSC zauważa, że przerwy między testami penetracyjnymi często trwają rok lub dłużej, i zaleca rutynowe testy bezpieczeństwa także w tym czasie (NCSC, Penetration testing). Dlatego ustal z wykonawcą jednorazowy test oraz to, co sprawdza się między testami, na przykład skany w pipeline.

Od czego zależy cena takiego sprawdzenia? Przede wszystkim od zakresu: liczby ról użytkowników, widoków i punktów API, integracji z innymi systemami oraz tego, czy w zakres wchodzi aplikacja mobilna. Wpływ ma też dostęp do kodu i dokumentacji, wielkość i jakość kodu, potrzeba retestu po poprawkach oraz to, czy sprawdzamy środowisko testowe czy produkcję. Dokładna wycena wymaga rozmowy o zakresie.

Przy utrzymaniu zawsze podpisujemy umowę powierzenia przetwarzania danych (art. 28 RODO). Jeśli chcesz sprawdzić swoją aplikację według tej checklisty, w konsultacji omawiamy zakres, ustalamy potrzebne dostępy i przygotowujemy wycenę prac. Przycisk do zapisu znajdziesz na końcu artykułu.

Najczęściej zadawane pytania

Jakie są najważniejsze zabezpieczenia aplikacji webowej?

Najważniejsze są: kontrola dostępu po stronie serwera, uwierzytelnianie wieloskładnikowe, zapytania parametryzowane i kodowanie danych wyjściowych, szyfrowanie TLS, aktualizowane zależności, logowanie zdarzeń oraz kopie zapasowe z testem odtwarzania. Kontrola dostępu otwiera listę OWASP Top 10:2025, a w danych OWASP wszystkie przetestowane aplikacje miały jakąś formę błędu dostępu.

Czym jest OWASP ASVS i który poziom wybrać?

OWASP ASVS to lista weryfikowalnych wymagań bezpieczeństwa aplikacji, w wersji 5.0.0 z 30 maja 2025 r. Poziom 1 zawiera minimum, poziom 2 OWASP wskazuje jako cel dla większości aplikacji, a poziom 3 dotyczy aplikacji z najbardziej wrażliwymi danymi. Poziom dobiera się do ryzyka, więc poziom 2 jest naturalnym punktem wyjścia dla aplikacji z danymi klientów.

Czy aplikacja webowa musi spełniać wymagania RODO i NIS2?

RODO dotyczy administratora i podmiotu przetwarzającego dane osobowe, a jego art. 32 wymaga środków bezpieczeństwa dopasowanych do ryzyka. NIS2 obejmuje tylko podmioty kluczowe i ważne z sektorów wskazanych w ustawie o krajowym systemie cyberbezpieczeństwa, obowiązującej w nowym brzmieniu od 3 kwietnia 2026 r. Czy firma jest objęta, sprawdzisz w załącznikach do ustawy.

Czy firewall aplikacyjny (WAF) wystarczy do ochrony aplikacji webowej?

WAF nie zastępuje zabezpieczeń w kodzie. Filtruje ruch HTTP i blokuje znane wzorce ataków, ale błąd typu brak sprawdzenia, czyje dane pobiera zalogowany użytkownik, wygląda w ruchu jak poprawne żądanie. Rekomenduję zaczynać od kontroli dostępu, walidacji i konfiguracji, a WAF traktować jako warstwę uzupełniającą.

Źródła

OWASP, Top 10:2025 (dostęp: listopad 2026): top10.owasp.org/2025; wprowadzenie (dane: ponad 2,8 mln aplikacji, 589 CWE): top10.owasp.org; A01 Broken Access Control: top10.owasp.org; A02 Security Misconfiguration: top10.owasp.org; A03 Software Supply Chain Failures: top10.owasp.org; A04 Cryptographic Failures: top10.owasp.org; A05 Injection: top10.owasp.org; A06 Insecure Design: top10.owasp.org; A07 Authentication Failures: top10.owasp.org; A08 Software or Data Integrity Failures: top10.owasp.org; A09 Security Logging and Alerting Failures: top10.owasp.org; A10 Mishandling of Exceptional Conditions: top10.owasp.org

OWASP, Application Security Verification Standard 5.0.0, 30.05.2025: asvs.owasp.org; treść rozdziałów V1-V16 (repozytorium, tag v5.0.0): github.com/OWASP/ASVS; poziomy ASVS: 0x03-What-is-the-ASVS; ocena i certyfikacja: 0x04-Assessment_and_Certification; OWASP API Security Top 10:2023: api-security.owasp.org; OWASP Web Security Testing Guide 4.2, Business Logic Testing: wstg.owasp.org

OWASP Cheat Sheet Series (dostęp: listopad 2026): cheatsheetseries.owasp.org; Authentication: link; Session Management: link; Password Storage: link; Authorization: link; IDOR Prevention: link; SQL Injection Prevention: link; Query Parameterization: link; XSS Prevention: link; Input Validation: link; Error Handling: link; File Upload: link; REST Security: link; Transport Layer Security: link; Cryptographic Storage: link; Secrets Management: link; HTTP Headers: link; Content Security Policy: link; CSRF Prevention: link; SSRF Prevention: link; Software Supply Chain Security: link; Vulnerable Dependency Management: link; Logging: link; Logging Vocabulary: link; Threat Modeling: link

Popularne narzędzia (dokumentacja autorów, dostęp: listopad 2026): npm audit: docs.npmjs.com; OWASP Dependency-Check: owasp.org; Dependabot: docs.github.com; Renovate: docs.renovatebot.com; Gitleaks: github.com/gitleaks; GitHub secret scanning: docs.github.com; Semgrep: docs.semgrep.dev; SonarQube: docs.sonarsource.com; CodeQL: codeql.github.com; OWASP ZAP: zaproxy.org; CycloneDX: cyclonedx.org; SPDX: spdx.dev

NIST, SP 800-218 SSDF 1.1, 02.2022: csrc.nist.gov; SP 800-218 Rev. 1 (SSDF 1.2), projekt z 17.12.2025: csrc.nist.gov; SP 800-63B-4, 07.2025: csrc.nist.gov

Verizon, 2026 Data Breach Investigations Report: verizon.com; NCSC (Wielka Brytania), Penetration testing: ncsc.gov.uk

ISO/IEC 27001:2022: iso.org; CIS Critical Security Controls v8.1: cisecurity.org

Rozporządzenie (UE) 2016/679 (RODO), art. 4 pkt 15, art. 9, art. 32, art. 33, motyw 35, EUR-Lex: eur-lex.europa.eu; dyrektywa (UE) 2022/2555 (NIS2), art. 21, EUR-Lex: eur-lex.europa.eu

UODO, Prezes UODO ponownie ukarał spółkę Morele.net, 8.02.2024: uodo.gov.pl; UODO, WSA oddalił skargę spółki Morele.net na decyzję Prezesa UODO, wyrok z 16.09.2024: uodo.gov.pl

Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252: eli.gov.pl; rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, Dz.U. 2024 poz. 773: eli.gov.pl, tekst; obwieszczenie Ministra Zdrowia z 4 września 2026 r. w sprawie ogłoszenia jednolitego tekstu rozporządzenia w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania, Dz.U. 2026 poz. 1391: eli.gov.pl

Covington, Article 29 Working Party Clarifies Scope of Health Data in Apps and Devices, 09.02.2015: insideprivacy.com; Grupa Robocza Art. 29, załącznik z 5.02.2015: ec.europa.eu

Te odcinki mogą Cię zainteresować:

Odcinek: 32

Testy penetracyjne - co to jest i czy ich potrzebujesz?

Zarządzanie ITProjekty ITBezpieczeństwo

Odcinek: 31

7 funkcji, które zniszczą Twoją firmę, jeśli zbudujesz je z AI bez wiedzy technicznej

AI

Odcinek: 30

Dostawca IT zawodzi

Współpraca z wykonawcą ITZarządzanie IT