Глоссарий
Что такое IDOR — увидеть чужие данные, просто изменив идентификатор
IDOR (Insecure Direct Object Reference, нарушение контроля доступа) позволяет изменить идентификатор в URL и добраться до чужих данных. Реальная защита: на сервере при каждом запросе проверять, можно ли этому пользователю обращаться к этому объекту.
«Я поменял id=124 на 125 в URL, и появился чужой счёт» — это и есть IDOR (нарушение контроля доступа). Разберём, как он работает и как надёжно его предотвратить (без шагов атаки).
Почему это случается
Аутентификация (кто вы) проходит, а авторизация (можно ли вам это делать?) отсутствует. Аутентификация и авторизация — разные вещи: возможность войти не означает разрешения видеть эти данные.
| Частый пробел | Результат |
|---|---|
| Доверие идентификатору как есть после входа | Подмените на чужой идентификатор — и всё проходит насквозь |
| Ошибка «не показано в UI = безопасно» | Прямое обращение к API открыто настежь |
| Нет проверки прав на создание/обновление/удаление | Не только просмотр — ещё подмена и удаление |
Почему это работает
Защита: проверяйте владение/разрешение на сервере, каждый раз
Проверяйте владение/разрешение для каждого объекта (самое важное)
Прямо перед возвратом или изменением данных проверяйте на сервере, что вошедший пользователь владеет этим объектом или имеет на него разрешение. Отказывайте, если нет.
Запрет по умолчанию
Новые эндпоинты начинаются с «запрещать всё, кроме того, что явно разрешено», чтобы забытая проверка давала отказ, а не открытый доступ.
Запрашивайте только «свои» строки
Встраивайте условие владельца в сам запрос (например, фильтр по id текущего пользователя). Пропускайте всё через один общий помощник авторизации, чтобы ни одно место вызова о нём не забыло.
Не путайте контроль в UI с защитой
Скрытие кнопки — это UX, а не безопасность. Считайте, что API вызывают напрямую, и решайте только на сервере. Держите случайные идентификаторы как вспомогательное средство, а не как механизм контроля.
Мнение этого сайта: неброско, но максимум воздействия — защитите тестами
IDOR технически скучен и легко упускается на code-review, при этом воздействие — высшего уровня («один клик раскрывает персональные данные всех»). Поэтому практичный ход — закрепить автоматический тест: будучи другим пользователем, обращение к чужому идентификатору должно возвращать 403. Принцип этого сайта — «никогда не защищаться в клиентском UI; решать только на сервере». Авторизация должна обеспечиваться механизмом при каждом запросе — её нельзя оставлять на человеческую внимательность.
Читать дальше
FAQ
QЧто происходит при IDOR?
Вошедший пользователь меняет идентификатор в URL или API (?id=124 на другое значение) и просматривает, редактирует или удаляет чужой счёт, заказ, персональные данные или файлы. Это флагман самого частого класса проблем (нарушение контроля доступа) и пугает тем, что не требует никаких особых инструментов.
QКакая защита главная?
При каждом запросе на сервере проверять: «может ли ЭТОТ вошедший пользователь действовать с ЭТИМ объектом?» Даже если идентификатор корректно сформирован, проверяйте владение/разрешение и отказывайте при их отсутствии (запрет по умолчанию). Никогда не полагайтесь на скрытие в клиентском UI.
QПредотвращают ли это UUID или случайные идентификаторы?
Они лишь делают идентификаторы труднее угадать — это не настоящее решение. Если идентификатор утечёт или будет передан, всё пройдёт насквозь. Держите рандомизацию как вспомогательное средство; реальная защита — всегда проверка владения/разрешения на сервере.