Broken access control wypada w testach najczęściej, bo dotyczy logiki biznesowej aplikacji, a tej nie da się sprawdzić automatycznym skanerem ani załatać biblioteką. Kategoria A01:2025 zbiera 40 różnych CWE i ponad 1,8 mln wystąpień w danych OWASP. Poniżej konkret: co dokładnie sprawdzić we własnej aplikacji i w jakiej kolejności.
- Skala jest policzalna — A01:2025 Broken Access Control ma 1 839 701 wystąpień, najwięcej w całym zbiorze danych OWASP.
- Procedury są gotowe — OWASP Web Security Testing Guide opisuje cztery testy autoryzacji, od WSTG-ATHZ-01 do WSTG-ATHZ-04.
- Metoda jest powtarzalna — macierz ról i endpointów wpięta w testy integracyjne, z weryfikacją kodu 200 wobec 403 dla każdej roli.
- Raport warto czytać krytycznie — MITRE odradza mapowanie konkretnych podatności na CWE-284.
Dlaczego broken access control wypada w testach częściej niż inne kategorie
Broken access control zajmuje pierwsze miejsce w OWASP Top 10:2025 i ma w zbiorze danych projektu najwyższą liczbę wystąpień. Tabela metryk kategorii A01:2025 podaje 40 zmapowanych CWE, 1 839 701 wystąpień i 32 654 powiązane CVE, przy średniej częstości występowania 3,74 %. Osiem z dziesięciu kategorii ósmej edycji wybrano ze zbioru obejmującego ponad 2,8 mln aplikacji. Pełny przegląd pozostałych kategorii zbiera omówienie wszystkich kategorii ryzyka OWASP Top 10.
Zakres kategorii rozszerzył się w edycji 2025 o Server-Side Request Forgery, czyli dawne A10:2021. CWE-918 figuruje dziś wśród 40 CWE przypisanych do A01:2025, więc testy autoryzacji obejmują też żądania, które serwer wykonuje w imieniu użytkownika do zasobu spoza jego uprawnień.
Niezależne potwierdzenie daje lista 2025 CWE Top 25 Most Dangerous Software Weaknesses ogłoszona przez MITRE. Do kontroli dostępu mapuje się dziewięć z dwudziestu pięciu pozycji: CWE-352, CWE-862, CWE-22, CWE-863, CWE-284, CWE-200, CWE-306, CWE-918 i CWE-639. Najwyżej stoją CWE-352 na trzecim i CWE-862 Missing Authorization na czwartym miejscu. Dwa zestawienia budowane inną metodyką wskazują ten sam obszar.
Tabelę metryk na stronie kategorii A01:2025 trzeba jednak czytać w całości. Max Coverage wynosi tam 100,00 %, Avg Coverage 42,93 %, a średnia częstość występowania 3,74 %. W metodyce OWASP coverage to odsetek aplikacji przetestowanych pod kątem danego CWE, a incidence rate — odsetek aplikacji, w których to CWE wykryto. Sto procent w tej tabeli oznacza więc pokrycie testami, nie odsetek aplikacji podatnych.
Co dokładnie testować: cztery procedury WSTG i ich odpowiedniki w API
Testować należy cztery obszary opisane w sekcji 4.5 Authorization Testing dokumentu OWASP Web Security Testing Guide (WSTG) w stabilnej wersji 4.2 z grudnia 2020, o identyfikatorach od WSTG-ATHZ-01 do WSTG-ATHZ-04. Identyfikatory mają prefiks ATHZ, nie AUTHZ.
Ta sama logika obowiązuje w interfejsach programistycznych, pod inną nomenklaturą: OWASP API Security Top 10 – 2023 rozdziela ją na Broken Object Level Authorization (BOLA), Broken Object Property Level Authorization i Broken Function Level Authorization.
| Co sprawdzasz | Procedura WSTG | Odpowiednik w API Top 10 | CWE |
|---|---|---|---|
| Dostęp do cudzego rekordu po podmianie identyfikatora | WSTG-ATHZ-04 Insecure Direct Object References | API1:2023 Broken Object Level Authorization | CWE-639, CWE-566 |
| Wywołanie funkcji zarezerwowanej dla wyższej roli | WSTG-ATHZ-03 Privilege Escalation | API5:2023 Broken Function Level Authorization | CWE-862, CWE-863 |
| Wejście na adres z pominięciem nawigacji i sesji | WSTG-ATHZ-02 Bypassing Authorization Schema | API5:2023 Broken Function Level Authorization | CWE-425, CWE-306 |
| Odczyt plików spoza katalogu aplikacji | WSTG-ATHZ-01 Directory Traversal File Include | Brak bezpośredniego odpowiednika | CWE-22 |
| Nadmiarowe pola w odpowiedzi i w przyjmowanym żądaniu | Brak bezpośredniego odpowiednika | API3:2023 Broken Object Property Level Authorization | CWE-200 |
Ostatni wiersz tabeli odpowiada dwóm zaleceniom z API3:2023 Broken Object Property Level Authorization: unikaniu generycznej serializacji obiektów metodami typu to_json() i rezygnacji z automatycznego bindowania danych wejściowych, czyli mass assignment.
Jak przetestować kontrolę dostępu we własnej aplikacji
Najskuteczniejszą metodą jest sformalizowanie uprawnień w macierzy i wykonanie każdego żądania z punktu widzenia każdej roli. Opisuje ją OWASP Authorization Testing Automation Cheat Sheet: macierz ról i usług staje się wejściem dla testów integracyjnych, a zasada brzmi „one test case by Point Of View”.
- Spisz role i endpointy do jednej macierzy. Wiersze to operacje z metodą HTTP i ścieżką, kolumny to role, w komórce oczekiwany wynik. Zasoby statyczne, pliki i eksporty też trafiają do macierzy.
- Przygotuj jeden przypadek testowy na rolę. Każda rola dostaje własną sesję lub token i wykonuje pełny zestaw żądań z macierzy, nie tylko te, do których ma prawo.
- Powtórz każde żądanie z sesją innej roli, bez sesji i po wylogowaniu. WSTG-ATHZ-02 wymienia dostęp poziomy, pionowy oraz dostęp bez uwierzytelnienia i po zakończeniu sesji. Ten ostatni wariant wychwytuje tokeny honorowane mimo wylogowania i w naszych testach wypada najczęściej tam, gdzie sesję unieważnia wyłącznie przeglądarka.
- Porównaj faktyczny kod HTTP z oczekiwanym. Kryterium jest proste: 200 tam, gdzie dostęp ma być dozwolony, 403 tam, gdzie ma być odmowa, i 401 dla żądania bez uwierzytelnienia. Przykład jednego wiersza macierzy: GET /api/zamowienia/1042 z tokenem właściciela — 200, to samo żądanie z tokenem innego klienta — 403, bez nagłówka Authorization — 401. Odpowiedź 200 z pustą treścią to nadal błąd, bo aplikacja obsłużyła nieuprawnione żądanie. Jeśli projekt świadomie zwraca 404, żeby nie potwierdzać istnienia rekordu, wpisz to do macierzy jako wynik oczekiwany.
- Sprawdź nagłówki obejściowe. WSTG-ATHZ-02 wskazuje X-Original-URL i X-Rewrite-URL jako sposób na ominięcie reguł warstwy pośredniczącej oraz X-Forwarded-For i X-Client-IP jako podszycie się pod zaufaną sieć. Powtórz z nimi odrzucone żądanie.
- Wepnij macierz w testy integracyjne w CI. Nowe endpointy przybywają szybciej, niż da się je przetestować ręcznie, a OWASP Authorization Cheat Sheet zaleca testy jednostkowe i integracyjne logiki autoryzacji.
Pracę ręczną wspierają narzędzia wskazane w przewodniku WSTG: OWASP ZAP z dodatkiem Access Control Testing oraz Burp Suite z rozszerzeniami AuthMatrix i Autorize. W projektach, które prowadzimy, najczęściej spotykamy układ, w którym kontrola dostępu działa poprawnie w warstwie interfejsu, a endpointy wołane przez ten interfejs nie sprawdzają uprawnień w ogóle.
Dlaczego „CWE-284” w raporcie z testów to sygnał ostrzegawczy
CWE-284 Improper Access Control jest przez MITRE oznaczone jako DISCOURAGED do mapowania realnych podatności. Powód jest metodyczny: to pozycja poziomu Pillar, najbardziej abstrakcyjna warstwa klasyfikacji, nadużywana i błędnie interpretowana przez pryzmat OWASP Top Ten. MITRE zaleca w jej miejsce identyfikatory opisujące mechanizm błędu: CWE-862, CWE-863, CWE-732 Incorrect Permission Assignment for Critical Resource lub CWE-306 Missing Authentication for Critical Function. Mimo tego zastrzeżenia CWE-284 stoi na dziewiętnastym miejscu listy MITRE — to dobra ilustracja skali samego problemu.
Wynika z tego praktyczne kryterium oceny raportu. Raport, który faktycznie testował autoryzację, wskazuje konkretną rolę, konkretny endpoint, żądanie odtwarzalne krok po kroku i otrzymany kod odpowiedzi, a CWE dobiera do mechanizmu: CWE-639 tam, gdzie klucz rekordu pochodzi od użytkownika, CWE-425 przy wymuszonym przeglądaniu adresów. Raport oparty na skanie zostawia zbiorcze CWE-284 bez roli i kroków odtworzenia. MITRE wiąże przy tym CWE-639 z IDOR i BOLA, więc ta pozycja spina słownictwo webowe ze słownictwem API.
Metodyczne ramy takiego testu opisuje NIST SP 800-115, którego sekcja 5.2 przedstawia czterofazową metodykę testu penetracyjnego.
Najczęstsze pytania o broken access control
Czym różni się eskalacja pozioma od pionowej?
Eskalacja pozioma oznacza dostęp do danych innego użytkownika o tych samych uprawnieniach, na przykład odczyt cudzego zamówienia po podmianie identyfikatora w adresie. Eskalacja pionowa to uzyskanie uprawnień wyższej roli, na przykład wywołanie funkcji administracyjnej z konta zwykłego użytkownika. OWASP Web Security Testing Guide rozdziela oba przypadki w procedurze WSTG-ATHZ-03.
Czy losowe identyfikatory GUID rozwiązują problem IDOR?
Nie rozwiązują. OWASP API Security zaleca losowe i nieprzewidywalne wartości typu GUID jako identyfikatory rekordów, ale traktuje to jako utrudnienie dla atakującego, a nie zastępstwo dla kontroli uprawnień. Aplikacja nadal musi weryfikować dostęp przy każdej operacji przyjmującej identyfikator. Identyfikator, który wyciekł w logach lub odnośniku, przestaje być nieprzewidywalny.
Czy skaner automatyczny wykryje broken access control?
Tylko częściowo. Skaner rozpoznaje wzorce techniczne, ale nie zna modelu biznesowego aplikacji, więc nie odróżni rekordu, który dana rola może zobaczyć, od takiego, którego zobaczyć nie powinna. Wykrycie eskalacji poziomej wymaga porównania odpowiedzi dla dwóch kont na tym samym żądaniu.
Jak często powtarzać testy kontroli dostępu?
Testy kontroli dostępu warto uruchamiać przy każdej zmianie ról, modelu danych lub zestawu endpointów, ponieważ to właśnie te zmiany tworzą nowe ścieżki obejścia. Macierz autoryzacji wpięta w testy integracyjne w CI daje ciągłą weryfikację między pełnymi testami penetracyjnymi prowadzonymi przez zespół zewnętrzny.
Jak Pentestica może pomóc
Testujemy kontrolę dostępu według procedur WSTG-ATHZ-01 do WSTG-ATHZ-04, z osobnym zestawem przypadków dla każdej roli i z weryfikacją odpowiedników API1, API3 i API5 z OWASP API Security Top 10. Raport budujemy według kryterium opisanego wyżej, a macierz autoryzacji przekazujemy w formie, którą zespół deweloperski wpina do własnych testów integracyjnych. Za zespołem stoi ponad 10 lat doświadczenia i setki zrealizowanych projektów. Sposób doboru zakresu opisuje strona usługi testów penetracyjnych, przykłady realizacji zbiera zestawienie zrealizowanych projektów, a wstępny zakres własnego testu wyznaczysz w konfiguratorze zakresu.
Źródła
Wszystkie adresy sprawdzone 15 września 2026 r.
- OWASP Top 10:2025 – A01:2025 Broken Access Control — strona kategorii z tabelą metryk, listą zmapowanych CWE i opisem scenariuszy ataku.
- OWASP Top 10:2025 – Introduction — metodyka ósmej edycji listy wraz z opisem zbioru danych i sposobu wyboru kategorii.
- OWASP Web Security Testing Guide v4.2 – 4.5 Authorization Testing — cztery procedury testowe WSTG-ATHZ wraz z technikami obejścia i listą narzędzi.
- OWASP API Security Top 10 – 2023: API1:2023 Broken Object Level Authorization — opis BOLA oraz zalecenia dotyczące weryfikacji dostępu i identyfikatorów rekordów.
- OWASP API Security Top 10 – 2023: API3:2023 Broken Object Property Level Authorization — zalecenia dotyczące serializacji obiektów i automatycznego bindowania danych wejściowych.
- OWASP Top 10 — metodyka zbierania danych (wydanie 2021) — definicje metryk coverage i incidence rate używanych w tabelach kategorii.
- OWASP Authorization Cheat Sheet — jedenaście zasad projektowania autoryzacji, od domyślnej odmowy po testy jednostkowe logiki uprawnień.
- OWASP Authorization Testing Automation Cheat Sheet — metoda budowy macierzy autoryzacji i automatyzacji testów na podstawie oczekiwanych kodów odpowiedzi.
- 2025 CWE Top 25 Most Dangerous Software Weaknesses — ranking MITRE w wydaniu 2025 z pozycjami dotyczącymi autoryzacji i kontroli dostępu.
- NIST SP 800-115 Technical Guide to Information Security Testing and Assessment — metodyka testów bezpieczeństwa, w tym czterofazowy model testu penetracyjnego w sekcji 5.2.
Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.