brak kontroli uprawnień (missing authorization)

Brak kontroli uprawnień (missing authorization) to błąd, w którym oprogramowanie w ogóle nie sprawdza, czy podmiot próbujący uzyskać dostęp do zasobu albo wykonać operację ma do tego prawo ^[1]. MITRE opisuje go jako słabość CWE-862 ^[1]. W zestawieniu CWE Top 25 za 2025 rok zajęła ona 4. miejsce, awansując o pięć pozycji względem poprzedniego roku ^[2]. Jest najprostszą postacią szerszej kategorii Broken Access Control: kontroli nie ma wcale, więc nie trzeba jej obchodzić.

Jak działa

Autoryzacja rozstrzyga, czy użytkownik, zwykle już uwierzytelniony, może wykonać konkretną czynność na konkretnym zasobie ^[1]. W kodzie oznacza to warunek przed operacją. Jeśli programista go pominie, funkcja wykona się dla każdego, kto potrafi ją wywołać. Ukrycie przycisku w interfejsie niczego nie zmienia, bo żądanie można wysłać ręcznie.

Schemat poniżej pokazuje, co dzieje się z żądaniem, gdy w łańcuchu brakuje kroku sprawdzenia uprawnień.

RYS. 1Żądanie bez sprawdzenia uprawnień

Odmiany

Brak kontroli uprawnień często myli się z pokrewnymi błędami. MITRE umieszcza CWE-862 pod ogólniejszą słabością CWE-285 (Improper Authorization) ^[1]. Różnice pokazuje tabela.

MITRE zauważa, że sama kontrola oparta na rolach nie chroni przed nadużyciem poziomym, czyli atakiem użytkownika na innego użytkownika z tą samą rolą ^[1]. Dlatego trzeba sprawdzać także, do kogo należy obiekt.

W WordPressie

Podręcznik wtyczek zaleca, by kod uruchamiać tylko wtedy, gdy bieżący użytkownik ma potrzebne uprawnienia ^[3]. Pokazuje przykład, w którym link do usuwania wpisów bez warunku pozwala dowolnemu odwiedzającemu przenosić wpisy do kosza, a rozwiązaniem jest current_user_can( 'edit_others_posts' ) ^[3]. Kilka mechanizmów WordPressa sprzyja jednak pomyłkom.

is_admin() nie sprawdza roli. Funkcja ustala tylko, czy żądanie dotyczy strony panelu administracyjnego. Dokumentacja podkreśla, że nie sprawdza, czy użytkownik jest administratorem, i odsyła do current_user_can() ^[4].

admin_init działa szerzej, niż sugeruje nazwa. Hak uruchamia się nie tylko na ekranach panelu, lecz także w admin-ajax.php i admin-post.php ^[6]. Kod podpięty pod ten hak bez sprawdzenia uprawnień może więc zostać wywołany przez zapytanie AJAX.

Akcje AJAX. Hak wp_ajax_{$action} uruchamia się dla każdego zalogowanego użytkownika, a wariant wp_ajax_nopriv_{$action} dla niezalogowanych ^[5]. Zalogowany znaczy tu także subskrybent albo klient sklepu, więc sama rejestracja pod wp_ajax_ nie zastępuje weryfikacji uprawnień.

add_action( 'wp_ajax_zapisz_opcje', function () {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error( null, 403 );
    }
    check_ajax_referer( 'zapisz_opcje' );
    // dopiero tu zmiana ustawień
} );

REST API. Każda trasa powinna mieć permission_callback; od WordPressa 5.5 jego brak powoduje komunikat _doing_it_wrong, a trasy publiczne mają jawnie używać __return_true ^[7]. Trasa, która zwraca true dla operacji zmieniających dane, to niezabezpieczony endpoint REST API (REST API abuse).

Warunek z nonce w przykładzie chroni przed CSRF, ale nie zastępuje sprawdzenia uprawnień: nonce potwierdza zamiar użytkownika, a nie jego prawo do operacji. Wzorcowe uprawnienia opisuje hasło role i uprawnienia użytkowników.

Zagrożenia i skutki

MITRE wymienia cztery grupy skutków ^[1]:

• odczyt danych wrażliwych bezpośrednio z niechronionego magazynu albo funkcji;
• modyfikację danych, do których atakujący nie powinien mieć dostępu;
• zdobycie uprawnień albo przyjęcie cudzej tożsamości, czyli eskalację uprawnień;
• nadmierne zużycie zasobów prowadzące do odmowy usługi.

Na stronie WordPress brak kontroli uprawnień w funkcji zapisującej opcje może pozwolić subskrybentowi zmienić domyślną rolę nowych kont albo adres strony. W połączeniu z otwartą rejestracją kończy się to nieautoryzowanym kontem administratora. Gdy funkcja jest dostępna także dla niezalogowanych, błąd staje się podatnością wykorzystywaną bez uwierzytelnienia.

Jak się bronić

MITRE zaleca podzielenie produktu na strefy: anonimową, zwykłą, uprzywilejowaną i administracyjną, oraz mapowanie ról na dane i funkcje ^[1]. Kontrola dostępu powinna obejmować logikę biznesową, a nie tylko ogólne zasoby, takie jak pliki czy rekordy bazy ^[1]. W WordPressie przekłada się to na kilka nawyków:

• sprawdzanie current_user_can() na początku każdej funkcji zmieniającej dane, niezależnie od haka, pod który jest podpięta ^[3];
• sprawdzanie konkretnego uprawnienia, a nie roli ani is_admin() ^[4];
• permission_callback z realnym warunkiem dla każdej trasy REST, która nie jest publiczna ^[7];
• przypisywanie użytkownikom ról zgodnie z zasadą najmniejszych uprawnień;
• aktualizowanie wtyczek, bo błędy tego typu usuwa zwykle łatka (patch) producenta.

MITRE zaznacza, że automatyczna analiza dynamiczna może znaleźć interfejsy niewymagające autoryzacji, ale ocena, czy to narusza logikę biznesową, wymaga analizy ręcznej ^[1]. Dlatego ten błąd dobrze wykrywa test penetracyjny i przegląd kodu.

Historia i przykłady

CERT Polska 20 listopada 2025 roku opublikował informację o podatnościach w oprogramowaniu SOPlanning ^[8]. Podatność CVE-2025-62293 sklasyfikowano jako Missing Authorization (CWE-862): z powodu braku kontroli uprawnień w funkcji Project Status każdy uwierzytelniony atakujący mógł dodawać, edytować i usuwać dowolne statusy przez punkt końcowy /status ^[8]. Podatne były wszystkie wersje poniżej 1.55 ^[8]. W tym samym komunikacie opisano także błędy XSS i przewidywalne tokeny odzyskiwania hasła ^[8], co pokazuje, że brak kontroli uprawnień rzadko występuje w oprogramowaniu jako jedyny problem.