IDOR (нарушение контроля доступа) — это когда замена id=124 на 125 в URL показывает чужой счёт. Разберём, как он работает и как надёжно его предотвратить (без шагов атаки).
Почему это случается
Аутентификация (кто вы) проходит, а авторизация (можно ли вам это делать?) отсутствует. Аутентификация и авторизация — разные вещи: возможность войти не означает разрешения видеть эти данные.
| Частый пробел | Результат |
|---|---|
| Доверие идентификатору как есть после входа | Подмените на чужой идентификатор — и доступ будет получен |
| Ошибка «не показано в UI = безопасно» | Прямое обращение к API ничем не блокируется |
| Нет проверки прав на создание/обновление/удаление | Не только просмотр — ещё подмена и удаление |
Почему это работает
Идентификаторы встречаются не только как ?id= в URL. Пути API (/api/orders/125), тела JSON ("userId": 125), URL скачивания файлов и скрытые поля форм требуют той же проверки — везде, где значение, присланное пользователем, выбирает, с каким объектом работать.
Смежные термины
IDOR — одна из форм нарушения контроля доступа. У него несколько названий, и его легко спутать с соседями.
| Термин | Чего не хватает | Пример |
|---|---|---|
| IDOR | Проверки владения/разрешения для каждого объекта | Пользователь A меняет идентификатор и видит счёт пользователя B |
| BOLA | То же, что IDOR (название в OWASP API Security) | /orders/{id} в API возвращает чужой заказ |
| Ошибка авторизации на уровне функций | Проверки прав для каждой функции | Обычный пользователь может вызвать API только для администраторов |
| Нарушение аутентификации | Самой проверки «кто вы» | API можно вызвать без входа |
В OWASP Top 10 нарушение контроля доступа (A01) стоит на первом месте в редакции 2025 года, как и в 2021-м. В OWASP API Security Top 10 (2023), посвящённом API, BOLA тоже на первом месте (API1:2023).
Реальные случаи: чужие данные видны после входа
Два случая в государственном секторе, разобранные на этом сайте, официально объяснили дефектами, внесёнными при обновлении систем, но по результату они устроены так же, как ошибка авторизации: вошедший пользователь мог добраться до чужих данных.
- Companies House, Великобритания (март 2026 г.): пользователи, вошедшие в WebFiling, могли при определённых действиях потенциально видеть домашние адреса и другие сведения директоров других компаний, а несанкционированная подача документов была технически возможна. Ведомство говорит, что это дефект, внесённый обновлением системы в октябре 2025 года, а не внешняя атака → подробный разбор (на английском)
- e-Tax Национального налогового агентства Японии (сентябрь 2026 г.): дефект после обновления «Моей страницы» позволил другим пользователям просматривать декларации по налогу на дарение и связанные документы 79 человек → подробный разбор (на английском)
В обоих случаях проверка входа работала. Не хватало проверки «может ли этот пользователь действовать с этим объектом?». И оба случились после изменения. Даже правильно сделанная система может потерять проверку при добавлении функции — поэтому автоматический тест, который запускается каждый раз, того стоит.
Защита: проверяйте владение/разрешение на сервере, каждый раз
Проверяйте владение/разрешение для каждого объекта (самое важное)
Прямо перед возвратом или изменением данных проверяйте на сервере, что вошедший пользователь владеет этим объектом или имеет на него разрешение. Отказывайте, если нет.
Запрет по умолчанию
Новые эндпоинты начинаются с «запрещать всё, кроме того, что явно разрешено», чтобы забытая проверка давала отказ, а не открытый доступ.
Запрашивайте только «свои» строки
Встраивайте условие владельца в сам запрос (например, фильтр по id текущего пользователя). Пропускайте всё через один общий помощник авторизации, чтобы ни одно место вызова о нём не забыло.
Не путайте контроль в UI с защитой
Скрытие кнопки — это UX, а не безопасность. Считайте, что API вызывают напрямую, и решайте только на сервере. Держите случайные идентификаторы как вспомогательное средство, а не как механизм контроля.
Как проверить своё приложение
Делайте это только в приложении, которое вы разрабатываете или которым управляете. Попытка сделать это на чужом сервисе может быть неправомерным доступом.
- Создайте тестовых пользователей A и B и дайте каждому по записи (заказ, файл и т. п.)
- Войдя как A, вызовите API просмотра, изменения и удаления с идентификатором, указывающим на запись B. Вызывайте API напрямую из инструментов разработчика или API-клиента, а не через UI
- Убедитесь, что каждый запрос отклоняется с 403 или 404. Проверьте также, что эндпоинты списков не включают записи B
- Превратите это в автоматический тест и добавляйте такой же тест при каждом новом эндпоинте
OWASP API Security Top 10 тоже рекомендует писать тесты, проверяющие механизм авторизации, и не выкатывать изменения, на которых эти тесты падают.
Мнение этого сайта: легко упустить, но последствия серьёзны, поэтому проверяйте автоматическими тестами
IDOR технически скучен и легко упускается на code-review, при этом последствия серьёзны («один клик раскрывает персональные данные всех»). Поэтому практичный ход — добавить автоматический тест: запрос чужого идентификатора от имени другого пользователя должен возвращать 403. Принцип этого сайта — «никогда не защищаться в клиентском UI; решать только на сервере». Авторизация должна обеспечиваться механизмом при каждом запросе — её нельзя оставлять на человеческую внимательность.
Источники (первичные)
- OWASP Top 10:2025, «A01 Broken Access Control» — top10.owasp.org (место в рейтинге; пример с небезопасными прямыми ссылками на объекты)
- OWASP API Security Top 10 2023, «API1:2023 Broken Object Level Authorization» — api-security.owasp.org (предотвращение; рекомендация по тестам)
- MITRE CWE-639: Authorization Bypass Through User-Controlled Key — cwe.mitre.org
- Источники по двум случаям (объявления Companies House и Национального налогового агентства) приведены в разборе каждого случая
Читать дальше
- Основы: Аутентификация и авторизация — в чём разница (вход ≠ авторизация; IDOR — одна из форм этой недостающей авторизации)
- Случаи: уязвимость WebFiling в Companies House · декларации по налогу на дарение в e-Tax, видимые другим пользователям (на английском)
- Глоссарий: Что такое CSRF (атака, злоупотребляющая вашим залогиненным состоянием) · Что такое OWASP Top 10 · Что такое фиксация сессии
- Основы: Основы безопасности · Бесплатные инструменты безопасности