Broken Access Control

Broken Access Control to kategoria błędów, w których aplikacja nie egzekwuje poprawnie reguł dostępu, przez co użytkownik działa poza przyznanymi mu uprawnieniami ^[1]. OWASP wskazuje, że takie awarie prowadzą zwykle do nieuprawnionego ujawnienia, modyfikacji albo zniszczenia danych lub do wykonania funkcji biznesowej wykraczającej poza limity użytkownika ^[1]. W liście OWASP Top 10 w edycji 2025 kategoria ta utrzymała pierwsze miejsce, a w 100% testowanych aplikacji znaleziono jakąś jej formę ^[1]. Nazwa jest parasolem: obejmuje zarówno całkowity brak kontroli uprawnień (missing authorization), jak i kontrolę obecną, ale błędną lub możliwą do obejścia.

Jak działa

Kontrola dostępu odpowiada na pytanie, co wolno zalogowanemu użytkownikowi. To autoryzacja, a nie uwierzytelnianie, które ustala tylko, kim ten użytkownik jest. Błąd z kategorii Broken Access Control pojawia się, gdy serwer wykonuje operację, nie sprawdzając uprawnień, albo sprawdza je na podstawie danych, które kontroluje klient.

OWASP opisuje trzy modelowe scenariusze ^[1]. W pierwszym aplikacja pobiera dane konta według parametru acct z adresu, więc wystarczy podmienić numer, żeby zobaczyć cudze konto. W drugim atakujący zgaduje adres strony administracyjnej i otwiera ją bez uprawnień. W trzecim cała kontrola dostępu siedzi w kodzie JavaScript w przeglądarce, a atakujący wywołuje punkt końcowy bezpośrednio, na przykład narzędziem curl ^[1]. Schemat poniżej pokazuje ten ostatni przypadek.

RYS. 1Kontrola tylko w przeglądarce

Odmiany

OWASP wymienia typowe postaci tej kategorii ^[1]. W edycji 2025 przypisano do niej 40 słabości CWE, które dały łącznie 1 839 701 wystąpień w danych i 32 654 powiązane CVE ^[1].

Do kategorii należą też CWE-862 (Missing Authorization), CWE-863 (Incorrect Authorization) i CWE-918, czyli SSRF ^[1]. W rankingu CWE Top 25 za 2025 rok CWE-862 zajęło 4. miejsce, CWE-863 17. miejsce, a CWE-639, słabość leżąca u podstaw IDOR, 24. miejsce ^[3].

W WordPressie

W WordPressie kontrola dostępu opiera się na rolach i uprawnieniach użytkowników. Rola to zestaw uprawnień, a kod powinien pytać o konkretne uprawnienie funkcją current_user_can(). Podręcznik wtyczek zaleca, by uruchamiać kod tylko wtedy, gdy bieżący użytkownik ma potrzebne uprawnienia, i pokazuje przykład, w którym brak takiego warunku pozwala dowolnemu odwiedzającemu przenosić wpisy do kosza ^[4].

if ( current_user_can( 'edit_others_posts' ) ) {
    add_action( 'init', 'wporg_delete_post' );
}

Najczęstsze miejsca błędów to akcje AJAX, formularze w panelu i trasy REST API dodane przez wtyczki. Dokumentacja REST API wymaga rejestrowania permission_callback dla każdej trasy; od WordPressa 5.5 jego brak wywołuje komunikat _doing_it_wrong ^[5]. Trasa publiczna ma jawnie używać __return_true ^[5], co ułatwia przegląd kodu: widać od razu, które trasy są otwarte. Trasa bez takiej kontroli to niezabezpieczony endpoint REST API (REST API abuse).

Częstym nieporozumieniem jest traktowanie nonce jako kontroli dostępu. Dokumentacja mówi wprost, że na nonce nigdy nie należy polegać przy uwierzytelnianiu, autoryzacji ani kontroli dostępu; funkcje trzeba chronić przez current_user_can() i zakładać, że nonce może zostać przejęty ^[6]. Nonce chroni przed CSRF, czyli przed żądaniem wysłanym w cudzym imieniu, ale nie odpowiada na pytanie, czy dany użytkownik może wykonać operację.

Patchstack w raporcie za pierwsze półrocze 2025 roku przypisał kategorii Broken Access Control 10,9% podatności w ekosystemie WordPressa ^[7]. Autorzy komentują, że ta częstość pokazuje, jak łatwo błędnie odwzorować role i uprawnienia WordPressa ^[7].

Zagrożenia i skutki

MITRE wymienia jako skutki braku autoryzacji odczyt danych wrażliwych, nieuprawnioną modyfikację danych, eskalację uprawnień oraz wyczerpanie zasobów prowadzące do odmowy usługi ^[2]. Na stronie WordPress przekłada się to na konkretne scenariusze: subskrybent zmieniający opcje wtyczki, nieuwierzytelniony gość eksportujący dane klientów sklepu, zmiana roli konta na administratora. Ostatni przypadek prowadzi zwykle do przejęcia konta i pełnej kontroli nad stroną.

Jak się bronić

OWASP podkreśla, że kontrola dostępu jest skuteczna tylko w zaufanym kodzie po stronie serwera, którego atakujący nie może zmodyfikować ^[1]. Zalecenia obejmują ^[1]:

• odmowę domyślną dla wszystkiego poza zasobami publicznymi;
• jeden mechanizm kontroli dostępu, używany w całej aplikacji;
• egzekwowanie własności rekordu, zamiast pozwalać na odczyt i edycję dowolnego rekordu;
• wyłączenie listowania katalogów (directory listing) i usunięcie z katalogu WWW metadanych, takich jak .git, oraz kopii plików;
• logowanie odmów dostępu i powiadamianie administratorów przy powtarzających się próbach;
• rate limiting dla API i kontrolerów;
• testy funkcjonalne kontroli dostępu w testach jednostkowych i integracyjnych.

MITRE zaleca dodatkowo kontrolę dostępu opartą na rolach, czyli RBAC, i sprawdzanie uprawnień także w logice biznesowej, nie tylko na poziomie zasobu ^[2]. W WordPressie oznacza to przypisywanie ról zgodnie z zasadą najmniejszych uprawnień oraz weryfikację uprawnień w każdej funkcji, która zmienia dane.

Historia i przykłady

CERT Polska 19 maja 2026 roku opublikował informację o podatnościach w produktach Sparx Systems ^[8]. Według komunikatu Pro Cloud Server do wersji 6.1 włącznie był podatny na atak typu Broken Access Control w komunikacji z bazą danych: z powodu braku weryfikacji uprawnień każdy uwierzytelniony użytkownik mógł wykonywać dowolne zapytania SQL w kontekście użytkownika bazy ^[8]. Podatność otrzymała numer CVE-2026-42096 i klasyfikację CWE-863 ^[8]. Ta sama publikacja opisuje CVE-2026-42097, w którym pominięcie parametru model w adresie pozwalało wykonywać zapytania SQL bez uwierzytelnienia ^[8].