IDOR (Insecure Direct Object Reference)

IDOR (Insecure Direct Object Reference) to odmiana błędu kontroli dostępu, w której aplikacja udostępnia rekord na podstawie identyfikatora podanego przez użytkownika i nie sprawdza, czy ten użytkownik ma prawo do tego rekordu. MITRE opisuje tę słabość jako CWE-639: mechanizm autoryzacji nie przeszkadza jednemu użytkownikowi w dostępie do danych innego, gdy ten zmieni wartość klucza wskazującego dane ^[1]. OWASP wymienia IDOR, czyli podgląd lub edycję cudzego konta przez podanie jego unikalnego identyfikatora, wśród przykładów kategorii Broken Access Control ^[3].

Jak działa

Według OWASP do powstania IDOR potrzebne są trzy elementy: obiekt (konto, dokument, zamówienie), odwołanie do niego (numer, UUID, slug) i brak sprawdzenia uprawnień przy dostępie ^[2]. Typowy przykład to adres z numerem użytkownika, w którym zmiana numeru na kolejny pokazuje dane innej osoby, bo aplikacja nie sprawdziła, czy pytający może je zobaczyć ^[2].

OWASP ilustruje to scenariuszem z parametrem acct: atakujący zmienia jego wartość w przeglądarce i otrzymuje dostęp do dowolnego konta, jeśli serwer nie weryfikuje go poprawnie ^[3]. Schemat poniżej pokazuje ten przebieg na stronie example.com.

RYS. 1IDOR przez zmianę numeru zamówienia

Błąd nie polega na tym, że identyfikator jest widoczny. Polega na tym, że serwer ufa mu bez sprawdzenia, do kogo należy obiekt. IDOR nie wymaga żadnej techniki wstrzyknięcia: wystarczy zmiana jednej liczby w żądaniu.

Odmiany

MITRE wiąże z CWE-639 kilka pojęć ^[1]. Dostęp do danych innego użytkownika na tym samym poziomie uprawnień to autoryzacja pozioma. Gdy klucz kontrolowany przez użytkownika działa jak flaga uprawnień, możliwa jest też eskalacja uprawnień w pionie, aż do dostępu administracyjnego ^[1].

W kontekście interfejsów API ta sama słabość nosi nazwę BOLA (Broken Object Level Authorization) ^[1]. Pokrewny jest mass assignment, w którym atakujący dopisuje do żądania pole, którego aplikacja nie powinna od niego przyjmować.

W WordPressie

W WordPressie IDOR pojawia się głównie we wtyczkach, które obsługują własne obiekty: zamówienia, rezerwacje, zgłoszenia formularzy, pliki klientów; zob. podatność we wtyczce. Rdzeń daje narzędzia, żeby sprawdzać uprawnienia do konkretnego obiektu, a nie tylko do rodzaju operacji.

Funkcja current_user_can() przyjmuje identyfikator obiektu, gdy sprawdzana zdolność jest meta‑zdolnością ^[4]. Meta‑zdolności, takie jak edit_post i edit_user, są mapowane przez map_meta_cap() na zdolności podstawowe ^[4]. Wywołanie current_user_can( 'edit_post', $post->ID ) odpowiada więc na pytanie, czy ten użytkownik może edytować ten konkretny wpis ^[4]. Dokumentacja odradza sprawdzanie nazw ról zamiast zdolności, bo daje to niepewne wyniki ^[4]; zob. role i uprawnienia użytkowników.

$order_id = absint( $_GET['id'] );
// podatne: brak sprawdzenia właściciela
$order = get_post( $order_id );
// poprawne: uprawnienie do tego obiektu
if ( ! current_user_can( 'edit_post', $order_id ) ) {
    wp_die( 'Brak dostępu', 403 );
}

Drugim miejscem są własne trasy REST. Parametr permission_callback sprawdza, czy użytkownik może wykonać działanie, zanim zostanie wywołana właściwa funkcja ^[5]. Od WordPressa 5.5 brak tego parametru powoduje komunikat _doing_it_wrong, a trasy publiczne powinny jawnie używać __return_true ^[5]. Trasa, która przyjmuje identyfikator obiektu, a w permission_callback sprawdza tylko, czy ktoś jest zalogowany, to typowy niezabezpieczony endpoint REST API.

Zagrożenia i skutki

MITRE wymienia jako skutki obejście kontroli dostępu, odczyt i zmianę danych innych użytkowników oraz w niektórych przypadkach dostęp administracyjny ^[1]. Prawdopodobieństwo wykorzystania ocenia jako wysokie ^[1]. W sklepie internetowym IDOR może oznaczać wgląd w adresy i zamówienia klientów, czyli wyciek danych, a przy danych osobowych także naruszenie ochrony danych osobowych. Przy operacjach zapisu atakujący może zmieniać lub usuwać cudze rekordy, co prowadzi do przejęcia konta albo utraty danych.

Jak się bronić

• Sprawdzenie przy każdym obiekcie. OWASP zaleca kontrolę dostępu dla każdego obiektu, spójnie przy odczycie, tworzeniu, zmianie, usuwaniu i eksporcie ^[2]. MITRE zaleca weryfikację uprawnień przy każdym dostępie do danych ^[1].
• Zapytania zawężone do użytkownika. Zamiast szukać obiektu w całej bazie, aplikacja powinna szukać go wśród obiektów bieżącego użytkownika ^[2].
• Własność rekordu. Model dostępu ma wymuszać własność rekordu zamiast zakładać, że użytkownik może tworzyć, czytać, zmieniać i usuwać dowolny rekord ^[3]. Poza zasobami publicznymi dostęp powinien być domyślnie zablokowany ^[3]; to zastosowanie zasady najmniejszych uprawnień.
• Trudne identyfikatory to za mało. GUID albo UUID utrudnia zgadywanie, ale według OWASP nie zastępuje sprawdzenia uprawnień ^[2].

Szerzej o sprawdzaniu uprawnień w kodzie mówi hasło weryfikacja uprawnień.

Historia i przykłady

W styczniu 2026 roku Sekurak opisał podatność IDOR w API Mozilli do zarządzania kontami Firefox ^[7]. Uwierzytelniony atakujący logujący się przez OAuth mógł usunąć konto innego użytkownika OAuth, znając tylko jego adres e‑mail, bo serwer nie sprawdzał, czy sesja należy do usuwanego konta ^[7]. Badacz zgłosił błąd w maju 2025 roku; Mozilla oceniła go jako High ^[7].

20 sierpnia 2026 roku CERT Polska opublikował informację o podatnościach w ATutor 2.2.4 ^[6]. Jedna z nich, CVE-2026-64969, to IDOR w obsłudze zdjęć profilowych: każdy uwierzytelniony użytkownik, także student, mógł wskazać w żądaniu POST cudzy member_id i trwale usunąć zdjęcie innej osoby, w tym instruktora lub administratora ^[6].