Наткнулись на API-эндпойнт, как на первом скрине? Не проходите мимо: вполне вероятно, что перед вами IDOR.
Иногда вместо числового ID разработчики используют ключевые слова вроде me или current. API принимает оба варианта: и
current, и 1234. Это делает IDOR-уязвимость менее заметной — но не менее опасной.☑️ Что пробуем
1. Подставляем вместо
current свой ID, например 1234.2. Запрос проходит? Отлично.
3. Теперь вставляем ID другого пользователя.
4. Если эл. почта чужого аккаунта меняется — уязвимость подтверждена.
🧠 Более сложный пример
В больших проектах часто два API-сервера:
• фронтенд — для клиента;
• бэкенд — для внутренней логики.
Проблема в том, что права доступа проверяются только на фронтенде.
🚀 Подключаем Path Traversal
1. Отправляем
/users/current/../1234/profile/email.2. Фронтенд распознает current как ID пользователя и отправляет запрос на бэкенд.
3. Бэкенд получает путь
/users/1234.4. Проверки нет — можно менять чужие данные.
🎯 Что получаем
Возможность изменить эл. почту другого пользователя или получить доступ к его данным. Это полноценная IDOR-уязвимость, усиленная Path Traversal.
🧩 Вывод
Если API позволяет подставлять ID через
../, me, current (и т. п.) — это повод проверить на IDOR. Особенно если бэкенд не валидирует входные данные.