IDOR (Insecure Direct Object Reference) - co to jest i jak go wykryć

IDOR - co to jest

IDOR to błąd kontroli dostępu. Aplikacja przyjmuje od użytkownika identyfikator obiektu - numer faktury, nazwę pliku, numer konta - i na jego podstawie zwraca albo zmienia dane. Sprawdza przy tym, czy użytkownik jest zalogowany, ale nie sprawdza, czy ten konkretny obiekt należy do niego. OWASP opisuje to krótko: aplikacja daje bezpośredni dostęp do obiektów na podstawie danych przekazanych przez użytkownika.

Skutki bywają poważne: jeden zalogowany klient może przeglądać dane wszystkich pozostałych, zmieniając numer w kolejnych żądaniach.

Jak działa podatność IDOR

Identyfikator obiektu może trafiać do serwera na kilka sposobów:

• w ścieżce adresu, np. /api/invoices/10482,
• w parametrze zapytania, np. ?documentId=7731,
• w treści żądania (JSON, formularz), np. w polu accountId,
• w argumencie zapytania GraphQL albo w nazwie pobieranego pliku.

IDOR dotyczy nie tylko odczytu. Ten sam błąd w operacjach zapisu pozwala zmienić adres dostawy innego klienta, anulować cudze zamówienie albo usunąć cudzy dokument. Zwykle chodzi o eskalację poziomą - dostęp do danych innego użytkownika w tej samej roli. Gdy zwykły użytkownik wywołuje funkcję administratora, mówimy o błędzie autoryzacji na poziomie funkcji (w API: BFLA).

Przykład demonstracyjny: IDOR w żądaniu HTTP

Poniższy przykład jest demonstracyjny - adres i dane są fikcyjne. Klient A jest zalogowany i ogląda swoją fakturę o numerze 10481. W żądaniu zmienia numer na 10482:

GET /api/invoices/10482 HTTP/1.1
Host: app.firma.example
Authorization: Bearer [token klienta A]

Serwer odpowiada fakturą klienta B:

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 10482, "customer": "Klient B", "issued": "2026-09-14", "items": 3}

Poprawnie zabezpieczona aplikacja odpowiedziałaby błędem 403 albo 404, bo faktura 10482 nie należy do klienta A. Ten sam błąd w operacji zapisu może wyglądać tak:

PATCH /api/orders/55120/address HTTP/1.1
Host: app.firma.example
Authorization: Bearer [token klienta A]
Content-Type: application/json

{"street": "Testowa 1", "city": "Wrocław"}

Jeśli serwer przyjmie tę zmianę dla cudzego zamówienia, atakujący przekieruje dostawę innego klienta.

Jak testuje się IDOR

OWASP WSTG v4.2 opisuje ten test jako WSTG-ATHZ-04. Kluczowe jest użycie co najmniej dwóch kont: tester tworzy lub odczytuje obiekty na jednym koncie i próbuje dostać się do nich z drugiego - zamiast zgadywać identyfikatory. W teście grey box prosimy zwykle o dwa konta w każdej roli, a każde żądanie z identyfikatorem sprawdzamy dla odczytu, zmiany i usunięcia, w każdej wersji API i w każdym miejscu, w którym identyfikator może się pojawić.

Skaner podatności rzadko wykrywa IDOR, bo nie wie, który obiekt należy do którego użytkownika - odpowiedź z cudzymi danymi wygląda dla niego jak poprawne działanie aplikacji.

IDOR w standardach OWASP

• OWASP Top 10:2025 - IDOR jest wymieniony jako przykład w kategorii A01:2025 Broken Access Control, która zajmuje pierwsze miejsce na liście OWASP Top 10.
• OWASP API Security Top 10 2023 - ten sam błąd w API to API1:2023 Broken Object Level Authorization (BOLA), pierwsze ryzyko na liście.
• CWE - typowa klasyfikacja to CWE-639: Authorization Bypass Through User-Controlled Key.

Powagę IDOR ocenia się zwykle w skali CVSS. W przykładzie z fakturami wektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N daje wynik 6.5 (Medium), ale w ocenie kontekstowej priorytet rośnie, gdy faktury zawierają dane osobowe i dane transakcji innych klientów.

Jak naprawić IDOR

• Sprawdzaj uprawnienia po stronie serwera przy każdym dostępie do obiektu - przy odczycie, zmianie i usunięciu.
• Ograniczaj zapytania do obiektów użytkownika, np. szukaj faktury wśród faktur zalogowanego klienta, a nie w całej bazie.
• Ustalaj tożsamość użytkownika na podstawie sesji lub tokenu, a nie parametru przesłanego w żądaniu.
• Traktuj losowe identyfikatory (np. UUID) jako dodatek - utrudniają zgadywanie, ale nie zastępują kontroli dostępu.
• Dodaj automatyczne testy autoryzacji dla każdej roli, żeby błąd nie wrócił przy kolejnej zmianie.

Typowe pomyłki

• "Ukryliśmy przycisk, więc nikt tam nie wejdzie." Interfejs nie jest zabezpieczeniem - żądanie można wysłać z pominięciem aplikacji, np. z narzędzia do testów API.
• "Chronimy tylko odczyt." Operacje zmiany i usuwania są równie ważne, a często groźniejsze.
• "Test z zewnątrz to wykryje." W teście black box bez kont testowych tester zwykle nie dociera do funkcji dostępnych po zalogowaniu, a to właśnie tam zwykle kryje się IDOR.

Powiązane pojęcia

• Test penetracyjny - kontrolowana symulacja ataku, w której IDOR wykrywa się testami ręcznymi.
• Retest - ponowne sprawdzenie po naprawie, które potwierdza, że kontrola dostępu działa dla każdej roli.
• OWASP ASVS - katalog wymagań, w tym wymagań dotyczących kontroli dostępu.

IDOR sprawdzamy w każdym teście z kontami użytkowników - zobacz testy penetracyjne aplikacji webowych i testy bezpieczeństwa API, gdzie ten sam błąd nazywa się BOLA. Dlaczego oferta bez kont testowych może go przeoczyć, wyjaśniamy w artykule jak porównać oferty na testy penetracyjne.