Bezpieczeństwo aplikacji webowych: OWASP Top 10:2025, dostęp, aktualizacje i RODO w praktyce

Większość włamań do aplikacji firmowych nie wymaga genialnego hakera. Wystarczy panel, w którym zmiana numeru w adresie pokazuje cudzą fakturę, biblioteka nieaktualizowana od dwóch lat albo hasło administratora bez drugiego składnika. Bezpieczeństwo aplikacji webowych to w większym stopniu kwestia nawyków przy budowie i utrzymaniu niż egzotycznych zabezpieczeń. Poniżej opisuję, na co zwracam uwagę, opierając się na aktualnej liście OWASP Top 10.

OWASP Top 10:2025: najczęstsze ryzyka

OWASP to fundacja, która co kilka lat publikuje listę najczęstszych kategorii ryzyk w aplikacjach webowych. Aktualna edycja to OWASP Top 10:2025:

1. 1.Broken Access Control: użytkownik widzi lub zmienia dane, do których nie powinien mieć dostępu.
2. 2.Security Misconfiguration: domyślne hasła, włączony tryb debugowania, zbyt szerokie uprawnienia serwera.
3. 3.Software Supply Chain Failures: zagrożenia z bibliotek, pakietów i narzędzi, z których zbudowana jest aplikacja.
4. 4.Cryptographic Failures: słabe szyfrowanie albo jego brak przy danych wrażliwych.
5. 5.Injection: wstrzyknięcie kodu, np. SQL, przez dane od użytkownika.
6. 6.Insecure Design: luki w samym projekcie procesu, a nie w kodzie.
7. 7.Authentication Failures: słabe logowanie, brak ochrony przed zgadywaniem haseł, źle obsługiwane sesje.
8. 8.Software or Data Integrity Failures: aktualizacje i dane przyjmowane bez weryfikacji ich pochodzenia.
9. 9.Security Logging and Alerting Failures: brak logów i alertów, przez co atak wychodzi na jaw po tygodniach.
10. 10.Mishandling of Exceptional Conditions: błędy i nietypowe sytuacje obsłużone tak, że otwierają furtkę.

Bezpieczeństwo aplikacji webowych zaczyna się od kontroli dostępu

Pierwsze miejsce na liście nie jest przypadkiem. W aplikacjach firmowych najczęściej spotykany błąd to sprawdzanie uprawnień tylko w interfejsie: przycisk „usuń” jest ukryty dla zwykłego użytkownika, ale samo zapytanie do serwera przechodzi. Zasada jest prosta: każde zapytanie do serwera sprawdza, kto pyta i czy ma prawo do tego konkretnego rekordu, niezależnie od tego, co pokazuje ekran.

Zależności i aktualizacje

Nowoczesna aplikacja składa się w większości z cudzego kodu: frameworka, bibliotek, pakietów. Trzecia pozycja listy OWASP dotyczy właśnie łańcucha dostaw oprogramowania. W praktyce oznacza to automatyczne powiadomienia o lukach w zależnościach, regularne aktualizacje i ostrożność przy dodawaniu nowych pakietów: każdy to kolejny autor, któremu ufasz. Aplikacja, której nikt nie aktualizuje, po roku ma zwykle kilka znanych luk w bibliotekach.

Logi, alerty i kopie zapasowe

RODO: bezpieczeństwo jako obowiązek prawny

Jeśli aplikacja przetwarza dane osobowe klientów lub pracowników, RODO wymaga odpowiednich środków technicznych i organizacyjnych, dobranych do ryzyka (art. 32). W razie naruszenia ochrony danych administrator zgłasza je do Prezesa UODO bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od jego stwierdzenia, chyba że naruszenie nie powoduje ryzyka dla osób (art. 33). Bez logów trudno w ogóle ustalić, co wyciekło i komu, więc logi są tu wymogiem praktycznym, nie tylko technicznym. Najczęstsze błędy małych firm opisuję w tekście o błędach RODO w małych firmach.

Jak sprawdzić aplikację, którą już masz

• Zaloguj się jako zwykły użytkownik i spróbuj otworzyć cudzy rekord, zmieniając identyfikator w adresie.
• Sprawdź, kiedy ostatnio aktualizowano framework i biblioteki.
• Zobacz, czy panel administratora ma logowanie dwuskładnikowe.
• Zapytaj, gdzie są kopie zapasowe i kiedy ostatnio je odtwarzano.

Szybki test podstaw dla strony firmowej opisuję w tekście o audycie bezpieczeństwa w 15 minut. Przy aplikacjach z danymi klientów warto przejść cały proces dokładniej, najlepiej zanim aplikacja trafi do użytkowników, a nie po pierwszym incydencie.

Źródła: OWASP Top 10:2025 i UODO: zgłaszanie naruszeń ochrony danych osobowych.