OWASP Top 10 2025 po polsku — lista podatności aplikacji webowych z przykładami (XSS, CSRF)

PawełInstruktor Cyberium Opublikowano 12 października 2026 17 min czytania Poziom: Początkujący

Co to jest OWASP Top 10?

OWASP Top 10 to dokument fundacji OWASP (Open Worldwide Application Security Project), który opisuje dziesięć najważniejszych kategorii ryzyk bezpieczeństwa aplikacji webowych. To nie norma ani lista kontrolna, tylko wspólny język programistów, testerów i pentesterów.

Według wprowadzenia do OWASP Top 10:2025 to ósma edycja listy. Dane przekazały organizacje, które testowały ponad 2,8 mln aplikacji. Osiem kategorii wybrano na podstawie tych danych, a dwie — na podstawie ankiety wśród praktyków, bo część ryzyk trudno wykryć automatycznymi testami. Każda kategoria grupuje kilka–kilkadziesiąt słabości z katalogu CWE (Common Weakness Enumeration — słownik typów błędów w oprogramowaniu); w całej liście jest ich 248.

Wersję 2025 ogłoszono w listopadzie 2025 roku; pełna treść jest na top10.owasp.org. Oficjalnego tłumaczenia na polski nie ma (stan na 12.10.2026), więc polskie nazwy poniżej są nasze — angielskie podajemy obok, bo takie spotkasz w raportach.

OWASP Top 10 2025 — lista A01–A10 po polsku

Co się zmieniło w OWASP Top 10 2025 względem 2021?

W OWASP Top 10:2025 są dwie nowe kategorie (A03 i A10) i jedno połączenie — SSRF (Server-Side Request Forgery, zmuszenie serwera do wysłania żądania pod adres wskazany przez atakującego), które w 2021 roku było osobną pozycją A10, trafiło do A01. Tak opisuje to wprowadzenie do wersji 2025.

Najczęstsze podatności aplikacji webowych po kolei — przykłady i ochrona

Każda kategoria OWASP Top 10:2025 w kilku zdaniach; sposoby ochrony w skrócie znajdziesz w tabeli wyżej.

A01:2025 Broken Access Control — naruszenie kontroli dostępu

Kontrola dostępu pilnuje, żeby użytkownik robił tylko to, do czego ma prawo. Według OWASP w 100% przetestowanych aplikacji znaleziono jakąś formę tego problemu, a kategoria ma najwięcej wystąpień w danych. Klasyczny przykład to IDOR (Insecure Direct Object Reference — bezpośrednie odwołanie do cudzego obiektu): aplikacja pokazuje dane konta po numerze z adresu i nie sprawdza, czy to twoje konto. Inny: panel administratora „ukryty” tylko w kodzie przeglądarki — wystarczy wysłać żądanie bezpośrednio.

Ochrona: sprawdzaj uprawnienia na serwerze przy każdym żądaniu, domyślnie odmawiaj dostępu, weryfikuj właściciela rekordu, unieważniaj sesję po wylogowaniu i testuj kontrolę dostępu w testach jednostkowych.

CSRF — co to jest i gdzie jest w OWASP Top 10 2025?

CSRF (Cross-Site Request Forgery, fałszowanie żądań między witrynami) to atak, w którym obca strona zmusza przeglądarkę zalogowanego użytkownika do wykonania akcji w zaufanej aplikacji — np. zmiany adresu e-mail czy hasła. Działa, bo przeglądarka automatycznie dołącza do żądania ciasteczko sesji. CSRF nie ma osobnej pozycji w OWASP Top 10:2025: słabość CWE-352 (CSRF) jest przypisana do A01 Broken Access Control.

Przykład: jesteś zalogowany w sklepie internetowym, a w innej karcie otwierasz stronę z ukrytym formularzem, który sam wysyła żądanie „zmień e-mail” do sklepu. Jeśli sklep nie wymaga tokenu CSRF ani nie sprawdza pochodzenia żądania, zmiana się wykona — a atakujący przejmie konto przez „przypomnij hasło”.

Ochrona według OWASP CSRF Prevention Cheat Sheet:

• Tokeny CSRF — losowe wartości dołączane do formularzy i sprawdzane przez serwer — najlepiej wbudowane we framework.
• Nagłówki Fetch Metadata (w nowoczesnych przeglądarkach), a jako dodatkowa warstwa — sprawdzanie nagłówka Origin.
• Żadnych zmian stanu aplikacji przez zapytania GET.
• Atrybut SameSite ciasteczek sesyjnych jako dodatkowa warstwa, a nie zamiennik tokenu.
• Pamiętaj, że XSS potrafi obejść wszystkie zabezpieczenia przed CSRF — dlatego obie podatności trzeba usuwać razem.

csrftoken — co to za ciasteczko? To domyślna nazwa ciasteczka z tokenem CSRF w Django (ustawienie CSRF_COOKIE_NAME, domyślnie z atrybutem SameSite=Lax — ustawienia). W formularzu token trafia do ukrytego pola csrfmiddlewaretoken, a w żądaniach JavaScript (AJAX) — do nagłówka X-CSRFToken. Żądanie bez poprawnego tokenu Django odrzuca odpowiedzią 403 Forbidden (dokumentacja Django). W szablonie wystarczy jeden znacznik:

<form method="post">{% csrf_token %}
  …
</form>

A02:2025 Security Misconfiguration — błędna konfiguracja zabezpieczeń

Błędna konfiguracja to system ustawiony niebezpiecznie: domyślne konta i hasła, włączone niepotrzebne usługi, listowanie katalogów na serwerze, szczegółowe komunikaty błędów ze śladem stosu albo zasobnik w chmurze (np. S3) otwarty dla całego internetu. Ta kategoria awansowała z 5. na 2. miejsce — według OWASP jakąś formę błędnej konfiguracji miało 100% przetestowanych aplikacji.

A03:2025 Software Supply Chain Failures — łańcuch dostaw oprogramowania

Twoja aplikacja to w dużej części cudzy kod: biblioteki, paczki, obrazy kontenerów, narzędzia do budowania. Ta kategoria obejmuje zarówno znane podatności w zależnościach, jak i złośliwe zmiany w nich. W ankiecie OWASP dokładnie 50% respondentów umieściło ją na 1. miejscu. OWASP przywołuje m.in. robaka Shai-Hulud z 2025 roku — pierwszego udanego samorozprzestrzeniającego się robaka w ekosystemie npm, który objął ponad 500 wersji paczek — oraz Log4Shell. Przykład z 2025 roku: CVE-2025-55182 („React2Shell”) w React Server Components (sam błąd to niebezpieczna deserializacja, CWE-502, czyli kategoria A08; dla aplikacji, która używa podatnej wersji Reacta, to ryzyko z A03) ma w NVD ocenę 10,0 w skali CVSS 3.1 (nadaną przez Meta, wydawcę Reacta; skala 0–10 mówi, jak groźna jest luka — więcej w artykule CVE i CVSS — co to jest), a CISA 5.12.2025 dopisała ją do katalogu KEV — listy podatności wykorzystywanych w atakach.

Ochrona: spis wszystkich zależności, także pośrednich (SBOM — Software Bill of Materials), stałe monitorowanie CVE, szybkie aktualizacje, paczki tylko z oficjalnych źródeł (najlepiej podpisane), MFA i rozdział obowiązków w repozytorium oraz potoku CI/CD.

A04:2025 Cryptographic Failures — błędy kryptograficzne

Chodzi o brak szyfrowania, słabe algorytmy, wyciek kluczy albo przewidywalną losowość. Przykład z opisu kategorii: baza haseł zapisana jako proste skróty bez soli — po wycieku można je szybko złamać. Drugi: strona, która nie wymusza HTTPS, pozwala w niezabezpieczonej sieci Wi-Fi przechwycić ciasteczko sesji.

A05:2025 Injection — wstrzykiwanie: SQL Injection, Command Injection i XSS

Injection to sytuacja, w której dane od użytkownika trafiają do interpretera — bazy danych, powłoki systemu, przeglądarki — i są wykonane jako polecenie. OWASP podaje, że to kategoria z największą liczbą powiązanych CVE: XSS (często, zwykle mniejsze skutki) to ponad 30 tys. CVE, a SQL Injection (rzadziej, poważne skutki) — ponad 14 tys.

SQL Injection w skrócie. Aplikacja skleja zapytanie SQL z tekstem od użytkownika, więc zmieniając parametr, można zmienić sens zapytania — np. pobrać wszystkie rekordy zamiast jednego; ochroną są zapytania parametryzowane. Jak działa SQL Injection, jakie ma rodzaje i jak go przećwiczyć w laboratorium, opisujemy w artykule SQL Injection — co to jest i jak się chronić.

Command Injection to to samo zjawisko w powłoce systemu: aplikacja wywołuje np. nslookup z nazwą domeny od użytkownika, a ten dopisuje średnik i własne polecenie. Ochrona: nie wywoływać powłoki z danymi użytkownika, używać bezpiecznych API i walidować dane listą dozwolonych wartości.

XSS to najczęstsza podatność w tej kategorii — opisujemy ją szerzej w osobnej sekcji niżej.

A06:2025 Insecure Design — niebezpieczny projekt

To błąd w samym pomyśle, a nie w implementacji: nawet idealnie napisany kod nie pomoże, jeśli projekt nie przewidział nadużycia. Przykład z opisu kategorii: sieć kin daje zniżkę grupową i wymaga zaliczki dopiero powyżej 15 osób, ale nie limituje liczby rezerwacji — atakujący blokuje kilkaset miejsc kilkoma żądaniami.

A07:2025 Authentication Failures — błędy uwierzytelniania

Aplikacja daje się przekonać, że atakujący jest kimś innym. Typowe przyczyny według OWASP: brak ochrony przed automatycznym zgadywaniem haseł i credential stuffing (logowanie hasłami z wycieków), domyślne hasła typu admin/admin, brak MFA, identyfikator sesji w adresie URL albo sesja, która nie wygasa po wylogowaniu.

A08:2025 Software or Data Integrity Failures — integralność oprogramowania i danych

Aplikacja ufa kodowi albo danym, których pochodzenia i nienaruszalności nie sprawdziła. Przykłady z opisu kategorii: urządzenia instalujące aktualizacje bez podpisu cyfrowego i niebezpieczna deserializacja (odtwarzanie obiektów z danych, które przysłał klient).

A09:2025 Security Logging & Alerting Failures — logowanie zdarzeń i alerty

Bez logów nie wykryjesz ataku, a bez alertów nikt nie zareaguje na czas. Nowa nazwa podkreśla właśnie alertowanie: we wprowadzeniu do listy OWASP pisze, że świetne logi bez alertów mają minimalną wartość. Przykład: aplikacja zapisuje udane logowania, ale nie nieudane, więc tysiące prób zgadnięcia hasła przechodzą niezauważone. Ciekawostka dla przyszłych pentesterów: w opisie kategorii OWASP uznaje za objaw problemu także to, że skanowanie Burpem czy ZAP-em nie wywołuje alertów.

A10:2025 Mishandling of Exceptional Conditions — błędna obsługa sytuacji wyjątkowych

Nowa kategoria (24 słabości CWE) dotyczy tego, co aplikacja robi, gdy coś pójdzie nie tak: brak pamięci, zerwane połączenie, brakujący parametr. Przykłady z opisu kategorii: komunikat błędu z pełnymi szczegółami bazy danych, który pomaga atakującemu przygotować SQL Injection, albo przelew przerwany w połowie — pieniądze zeszły z jednego konta, a operacja nie została wycofana.

XSS — co to jest i jak działa atak XSS?

XSS (Cross-Site Scripting) to podatność, przez którą aplikacja wstawia na stronę niezaufane dane w taki sposób, że przeglądarka traktuje je jako kod — zwykle JavaScript. Według OWASP XSS Prevention Cheat Sheet skutkiem może być podszycie się pod konto ofiary, śledzenie jej działań, wczytanie obcych treści czy kradzież danych. W OWASP Top 10:2025 XSS jest częścią kategorii A05 Injection.

Polski przykład z 2026 roku: CERT Polska opisał podatność CVE-2026-6841 (21.05.2026) w systemie zgłoszeń Request Tracker, znalezioną przez członka zespołu CERT Polska podczas wewnętrznych testów — reflected XSS w parametrze Page (poprawione w wersjach 5.0.10 i 6.0.3). Atakujący mógł przygotować adres URL, którego otwarcie wykonywało dowolny kod JavaScript w przeglądarce ofiary.

Rodzaje XSS: reflected, stored i DOM-based

• Reflected XSS (odbity) — złośliwa treść jest w adresie lub formularzu i „odbija się” w odpowiedzi serwera, np. na stronie wyników wyszukiwania. Ofiara musi kliknąć przygotowany link.
• Stored XSS (trwały) — treść zapisuje się w aplikacji (komentarz, nazwa profilu, wiadomość) i uruchamia u każdego, kto ją wyświetli. Zwykle najgroźniejszy, bo nie wymaga klikania w podejrzany link.
• DOM-based XSS — problem jest w kodzie JavaScript po stronie przeglądarki, który wstawia dane (np. z fragmentu adresu po #) do strony niebezpieczną metodą, jak innerHTML. Serwer może w ogóle nie widzieć złośliwej treści.

Przykład XSS: podatny kod i poprawka

Najprostszy przypadek: strona wyszukiwarki wypisuje frazę z adresu bez kodowania.

<?php
// podatne: fraza z adresu trafia na stronę jako HTML
echo "Wyniki dla: " . $_GET['q'];

// poprawka: kodowanie wyjścia — znaki & < > " ' zamieniane na encje HTML
echo "Wyniki dla: " . htmlspecialchars($_GET['q'] ?? '', ENT_QUOTES, 'UTF-8');

Jeśli uruchomisz pierwszą wersję u siebie (np. php -S localhost:8000) i dopiszesz do adresu ?q=<b>test</b>, a słowo wyświetli się pogrubione, przeglądarka zinterpretowała twoje dane jako HTML — w tym miejscu da się wstrzyknąć także skrypt. W drugiej wersji zobaczysz dosłownie <b>test</b> jako tekst.

Ten sam błąd w JavaScripcie (DOM-based) i poprawka:

// podatne: dane z adresu wstawiane jako HTML
wynik.innerHTML = decodeURIComponent(location.hash.slice(1));

// bezpieczne: dane wstawiane jako tekst
wynik.textContent = decodeURIComponent(location.hash.slice(1));

Jak się chronić przed XSS?

OWASP podkreśla, że nie ma jednej techniki, która usuwa XSS — potrzebna jest kombinacja:

1. Framework z automatycznym kodowaniem (React, Angular, Vue, szablony serwerowe) — i ostrożność przy „furtkach”, takich jak dangerouslySetInnerHTML w React czy bypassSecurityTrustAs* w Angularze.
2. Kodowanie wyjścia zależne od kontekstu — inaczej w treści HTML, inaczej w atrybucie, w JavaScripcie czy w adresie URL.
3. Sanityzacja HTML, gdy użytkownik musi wpisywać sformatowany tekst — OWASP rekomenduje bibliotekę DOMPurify.
4. Bezpieczne „ujścia” danych — textContent zamiast innerHTML.
5. Dodatkowe warstwy: Content Security Policy (CSP — nagłówek ograniczający, skąd strona może ładować skrypty), atrybut HttpOnly dla ciasteczek sesji, Trusted Types. OWASP zaznacza, że CSP i WAF to uzupełnienie, a nie zamiennik kodowania wyjścia.

Walidacja danych wejściowych pomaga, ale według OWASP nie zastępuje tych zabezpieczeń: aplikacja, która chroni 99 miejsc i pomija jedno, nadal jest podatna.

Jak nauczyć się OWASP Top 10 w praktyce?

Najskuteczniej: zrozumieć HTTP, nauczyć się przechwytywać i modyfikować żądania w Burp Suite (narzędzie pośredniczące między przeglądarką a aplikacją), a potem przećwiczyć każdą podatność samodzielnie w legalnym laboratorium — najpierw ją znaleźć, potem wykorzystać, na końcu opisać poprawkę w raporcie. Czytanie listy OWASP Top 10 bez praktyki daje słownik, ale nie umiejętność. AI potrafi podpowiedzieć poprawkę, ale żeby zauważyć, że innerHTML z danymi z adresu to XSS, trzeba rozumieć mechanizm — dlatego ta wiedza zyskuje na wartości także w czasach AI.

Dobre, niezależne miejsca do ćwiczeń:

• PortSwigger Web Security Academy — darmowe materiały i laboratoria od twórców Burp Suite, po angielsku.
• OWASP Juice Shop — celowo podatny sklep od OWASP do uruchomienia we własnym środowisku; projekt jest aktywny (wydanie v20.3.0 z 11.10.2026).
• Platformy z laboratoriami, takie jak TryHackMe czy Hack The Box — porównujemy je w artykule TryHackMe, Hack The Box czy kurs po polsku.

Gdzie w Cyberium uczysz się OWASP Top 10?

Cyberium — polski kurs cyberbezpieczeństwa online — ma dwa szkolenia o aplikacjach webowych: 7 (podstawy, misje #03 i #04) i 8 (techniki zaawansowane, misja #05); tabela pokazuje, gdzie ćwiczysz poszczególne kategorie.

Cyberium uczy patrzenia na aplikację oczami pentestera — kogoś, kto sam znajduje, wykorzystuje i opisuje podatności. Ten punkt widzenia przydaje się też przy projektowaniu: w szkoleniu 3 poznajesz modelowanie zagrożeń metodą STRIDE (podstawa ochrony przed A06), ocenę podatności w CVSS i plany reagowania na incydenty. Kolejnym krokiem po kursie może być pogłębienie praktyk zespołów programistycznych — SBOM, monitorowanie i alerty — o których piszemy w artykule IT security dla administratorów i programistów. Jak wygląda cały test, opisujemy w poradniku pentest — co to jest.

Nauka samodzielna, platforma czy kurs — porównanie

Darmowe materiały są świetnym uzupełnieniem, a kurs po polsku daje gotową kolejność — do XSS i SQL Injection dochodzisz po rekonesansie, eksploitacji i nauce raportu. Jeśli wybierasz między formami nauki, przydadzą się 10 pytań przed wyborem kursu cyberbezpieczeństwa, a cały plan od zera znajdziesz w artykule jak zostać specjalistą ds. cyberbezpieczeństwa.

Jak zacząć z Cyberium?

Jeśli chcesz nauczyć się OWASP Top 10 w praktyce, po polsku i w jednym środowisku, zobacz nasz kurs cyberbezpieczeństwa od podstaw:

• Dostęp od razu po zakupie — 176 lekcji (89 wideo) i 57 laboratoriów w przeglądarce (CyberBox), ponad 70 godzin materiału.
• 5 misji projektowych do portfolio i CV, w tym #03, #04 i #05 z aplikacji webowych.
• Egzamin praktyczny C:CCE — test penetracyjny maszyny (12 godzin) i raport (48 godzin); po zaliczeniu dostajesz certyfikat.
• Subskrypcja z rezygnacją w każdej chwili; kursanci kończą cały kurs zwykle w 3–4 miesiące.

Zanim zdecydujesz, obejrzyj lekcje DEMO i zobacz, jak wygląda nauka.

Najczęstsze pytania (FAQ)

Podsumowanie

OWASP Top 10:2025 to dziesięć kategorii ryzyk — od naruszeń kontroli dostępu (A01, z CSRF i SSRF) po nową A10 o obsłudze błędów — a XSS i SQL Injection należą do A05 Injection i znikają, gdy oddzielasz dane od kodu. Najszybciej zrozumiesz je, przećwiczywszy je samodzielnie w laboratorium — po polsku, z gotową kolejnością i wsparciem eksperta zrobisz to na naszym kursie cyberbezpieczeństwa online.