OWASP (Open Worldwide Application Security Project, wcześniej Open Web Application Security Project) to globalna, niekomercyjna organizacja non-profit zajmująca się bezpieczeństwem aplikacji webowych, a także IoT i systemów. OWASP udostępnia darmowe zasoby — narzędzia, dokumentację, metodologie, szkolenia i społeczność ekspertów — co pozwala na niezależne od firm technologicznych doskonalenie bezpieczeństwa oprogramowania.

Jednym z najbardziej znanych inicjatyw OWASP jest OWASP Top 10 — zestaw dziesięciu najpoważniejszych zagrożeń dla aplikacji webowych, aktualizowany co 3–4 lata na podstawie danych z testów bezpieczeństwa i opinii ekspertów.

OWASP Top 10. Opisy podatności

OWASP Top 10:2025 to najnowsza edycja najbardziej znanego zestawienia kluczowych zagrożeń bezpieczeństwa aplikacji webowych, opracowana przez Open Web Application Security Project (OWASP). Lista powstaje na podstawie globalnych danych z realnych incydentów, badań społeczności oraz ankiet branżowych i stanowi punkt odniesienia dla zespołów developerskich, security i audytorów. W edycji 2025 widoczne są zarówno kontynuacje znanych problemów (np. Broken Access Control czy Injection), jak i nowe akcenty wynikające z ewolucji sposobu tworzenia oprogramowania. Szczególną uwagę zwrócono na: bezpieczeństwo łańcucha dostaw oprogramowania, odporność aplikacji na błędy i sytuacje wyjątkowe, znaczenie poprawnej konfiguracji, logowania i monitorowania.

OWASP Top 10:2025 nie jest kompletną listą wszystkich podatności, lecz praktycznym przewodnikiem priorytetów, pomagającym organizacjom projektować, budować i utrzymywać bezpieczniejsze aplikacje w nowoczesnych środowiskach (cloud, CI/CD, microservices).

1. A01:2025 – Broken Access Control (Złamana kontrola dostępu)

Luki w kontroli dostępu pozwalają użytkownikom na wykonywanie akcji, do których nie mają uprawnień.

Najczęściej spotyka się:

manipulowanie parametrami w URL lub w formularzach,
brak rozróżnienia ról (np. zwykły użytkownik może uzyskać dostęp do panelu admina),
brak odpowiedniej walidacji po stronie serwera.

Przykład: Zwykły użytkownik może pobrać faktury innych klientów, wpisując ręcznie inne ID.

Rekomendacje:

Egzekwowanie kontroli dostępu po stronie serwera, nigdy tylko w JS/front-endzie
Zasada „domyślnego zakazu” – brak dostępu, dopóki nie zostanie jawnie przyznany
Testy penetracyjne i automatyczne skanery wykrywające manipulację parametrami

2. A02:2025 – Security Misconfiguration (Niewłaściwa konfiguracja)

Najczęściej spotykana luka w praktyce. Obejmuje:

pozostawione domyślne hasła lub ustawienia (np. admin/admin),
włączone tryby debug w produkcji,
niepotrzebnie odsłonięte porty i usługi,
nadmiarowe komunikaty błędów (stack trace, wersje bibliotek).

Przykład: Aplikacja ujawnia w logach pełny stack trace z wersją frameworka, co pozwala atakującemu przygotować exploit.

Rekomendacje:

Stosowanie Infrastructure as Code (IaC) do standaryzacji konfiguracji
Hardenowanie serwerów i usług
Regularne testy konfiguracji i skany bezpieczeństwa (np. CIS Benchmarks)

3. A03:2025 – Software Supply Chain Failures

Podatność dotyczy zagrożeń wynikających z zależności od zewnętrznych komponentów: bibliotek, frameworków, narzędzi CI/CD, obrazów kontenerów czy usług SaaS. Ataki na łańcuch dostaw polegają na wstrzyknięciu złośliwego kodu lub wykorzystaniu przejętych/niezaufanych źródeł, co pozwala atakującemu wpłynąć na aplikację bez bezpośredniego ataku na jej kod.

Przykład: Projekt używa popularnej biblioteki z publicznego repozytorium. Atakujący przejmuje konto maintenera i publikuje nową wersję z backdoorem. Automatyczny pipeline CI aktualizuje zależność, a złośliwy kod trafia do produkcji.

Rekomendacje:

Stosowanie SBOM (Software Bill of Materials) i inwentaryzacja zależności
Weryfikowanie integralności: podpisy cyfrowe, hashe, zaufane repozytoria
Ograniczenie automatycznych aktualizacji; używanie pinowania wersji i przeglądu zmian.

4. A04:2025 – Cryptographic Failures (Błędy kryptograficzne)

Kategoria obejmuje wszelkie problemy związane z ochroną danych wrażliwych. Dawniej była opisywana jako „Sensitive Data Exposure”, lecz teraz skupia się na przyczynach:

brak szyfrowania w transmisji (np. użycie HTTP zamiast HTTPS),
słabe algorytmy (np. MD5, SHA-1, RC4),
niewłaściwe zarządzanie kluczami i certyfikatami,
przechowywanie haseł w postaci jawnej lub z użyciem prostego hash() bez saltingu.

Przykład: Aplikacja e-commerce przesyła numery kart kredytowych przez HTTP, co pozwala podsłuchać dane w sieci publicznej Wi-Fi.

Rekomendacje:

Stosowanie TLS 1.2+ z bezpiecznymi zestawami szyfrów
Użycie sprawdzonych bibliotek kryptograficznych (np. libsodium, Bouncy Castle)
Hasła – zawsze hashowane z bcrypt/argon2 i unikalnym soleniem
Regularny audyt konfiguracji certyfikatów SSL/TLS (np. Qualys SSL Labs)

5. A05:2025 – Injection (Wstrzykiwanie kodu)

Ataki typu Injection polegają na wstrzyknięciu nieautoryzowanych danych do interpreterów (SQL, NoSQL, OS, LDAP, XML).
Do tej kategorii przeniesiono również XSS (Cross-Site Scripting).

Przykłady:

SQL Injection
OS Command Injection
XSS

Rekomendacje:

Stosowanie parametryzowanych zapytań (prepared statements)
Walidacja i filtrowanie danych wejściowych
Kodowanie danych wyjściowych (HTML, JSON, XML)
Web Application Firewall (WAF) jako dodatkowa warstwa ochrony

6. A06:2025 – Insecure Design (Niebezpieczny design)

Ta nowa kategoria skupia się na lukach wynikających z błędów w architekturze i projekcie systemu, nie tylko w implementacji.
Często wynika z braku:

analizy zagrożeń (threat modeling)
zasad „least privilege” i separacji obowiązków
mechanizmów obronnych na etapie projektowania (np. brak MFA, brak limitów sesji)

Przykład: System bankowy zaprojektowany tak, że wszystkie operacje finansowe przechodzą przez jeden punkt awarii, bez redundancji i monitoringu.

Rekomendacje:

Wdrożenie secure by design i security by default
Warsztaty threat modeling na etapie planowania funkcjonalności
Regularny code review i architektoniczne audyty bezpieczeństwa

Atakowanie aplikacji webowych. Kurs video. Zrozum i wykorzystaj luki w zabezpieczeniach

Umiejętność obrony przed atakami na aplikacje webowe jest dziś jedną z najważniejszych kompetencji w branży IT. Ofiarami cyberataków padają zarówno duże korporacje, jak i małe biznesy, a głównym celem hakerów jest pozyskanie danych wrażliwych. Dlatego skuteczne zabezpieczanie informacji użytkowników jest wyzwaniem, ale i podstawą w budowaniu zaufan

Autor:

Maciej Pypeć

Ocena:

6.0/6

89.25 zł

(39,90 zł najniższa cena z 30 dni)

7. A07:2025 – Authentication Failures (Błędy uwierzytelniania i identyfikacji)

Dotyczą błędów w mechanizmach logowania i sesji.

Najczęstsze przypadki:

brak limitów prób logowania → brute force, credential stuffing,
brak wieloskładnikowego uwierzytelniania (MFA),
sesje bez limitu czasu,
tokeny sesji przekazywane w URL.

Przykład: Użytkownik po wylogowaniu nadal ma aktywną sesję, a link sesyjny przesłany znajomemu daje mu dostęp do konta.

Rekomendacje:

Stosowanie MFA
Sesje powinny wygasać (absolute timeout i inactivity timeout)
Tokeny przechowywane wyłącznie w HttpOnly Secure cookies
Monitorowanie i blokowanie podejrzanych prób logowania

8. A08:2025 – Software and Data Integrity Failures (Błędy integralności oprogramowania i danych)

Dotyczy braku weryfikacji integralności komponentów i danych. Szczególnie istotne w dobie CI/CD.

Przykłady:

aktualizacje oprogramowania pobierane bez podpisów,
używanie niezaufanych repozytoriów (np. paczki npm/PyPI),
brak mechanizmów kontroli integralności danych (checksum, podpis cyfrowy).

Atak typu supply chain – zainfekowana paczka npm (np. „event-stream”) rozprzestrzenia malware.

Rekomendacje:

Weryfikacja podpisów cyfrowych pakietów
Ograniczenie źródeł zewnętrznych zależności
Bezpieczne procesy CI/CD (signed builds, reproducible builds)

9. A09:2025 – Logging & Alerting Failures (Braki w logowaniu i monitoringu)

Bez odpowiednich logów i alertów organizacja nie zauważy ataków lub nie będzie mogła ich przeanalizować.
Często spotykane:

brak logowania zdarzeń bezpieczeństwa,
logowanie niekompletne (np. bez adresu IP, timestampu),
brak centralizacji i korelacji logów.

Przykład: Atakujący przez kilka miesięcy pobiera dane z API, ale organizacja nie ma mechanizmów SIEM i incydent wykrywany jest dopiero po wycieku.

Rekomendacje:

Wdrożenie centralnego systemu logowania (np. ELK, Splunk)
Alarmy w czasie rzeczywistym dla podejrzanych aktywności
Regularne testy planów reakcji na incydenty

10. A10:2025 – Mishandling of Exceptional Conditions

Podatność dotyczy nieprawidłowej obsługi wyjątków, błędów i sytuacji brzegowych w aplikacji. Brak właściwego zarządzania wyjątkami może prowadzić do ujawnienia wrażliwych informacji (np. stack trace, konfiguracja), pominięcia kontroli bezpieczeństwa, niestabilności aplikacji lub podatności typu DoS.

Przykład: Aplikacja webowa w przypadku błędu bazy danych zwraca użytkownikowi pełny stack trace z nazwami tabel, zapytań SQL i ścieżkami plików. Atakujący wykorzystuje te informacje do przygotowania dalszego ataku (np. SQL Injection lub LFI).

Rekomendacje:

Stosuj centralną obsługę wyjątków i jednolite komunikaty błędów dla użytkowników
Nie ujawniaj szczegółów technicznych (stack trace, konfiguracja, klucze
Loguj błędy bezpiecznie (z maskowaniem danych wrażliwych)

Studium przypadku - analiza podatności

W 2024 roku badacze bezpieczeństwa Ian Carroll i Sam Curry odkryli poważną podatność typu SQL Injection w systemie FlyCASS, który jest wykorzystywany przez mniejsze linie lotnicze do integracji z amerykańskim systemem weryfikacji załóg TSA – Known Crewmember (KCM) oraz Cockpit Access Security System (CASS). Wykorzystując tę lukę, badacze byli w stanie zalogować się jako administratorzy i dodawać fałszywe rekordy załogi, w tym zdjęcia i numery identyfikacyjne, do baz danych wykorzystywanych przez TSA do weryfikacji tożsamości pracowników linii lotniczych w punktach kontrolnych. Dzięki temu atakujący mogli uzyskać dostęp do strefy zastrzeżonej na lotniskach, w tym do kokpitów samolotów. Pomimo zgłoszenia tej podatności do Departamentu Bezpieczeństwa Krajowego (DHS) i TSA, nie podjęto odpowiednich działań naprawczych, a agencje zbagatelizowały zagrożenie.

Atak ten stanowi poważne przypomnienie o znaczeniu odpowiedniej walidacji danych wejściowych i zabezpieczeń w systemach, które mają krytyczne znaczenie dla bezpieczeństwa narodowego. Pomimo że podatność została wykorzystana w celach badawczych, jej potencjalne konsekwencje mogłyby być katastrofalne, gdyby trafiła w ręce nieuprawnionych osób. Incydent ten uwypukla potrzebę ciągłego monitorowania i audytu systemów oraz szybkiego reagowania na zgłoszenia dotyczące luk bezpieczeństwa.