Эндпоинт GET /orders/{id} проверяет, что пользователь аутентифицирован, и возвращает заказ по идентификатору. Что здесь не так?
- Что такое IDOR?
- Почему нельзя проверять только аутентификацию?
Проверено «кто ты» (аутентификация), но не «можно ли тебе этот заказ» (авторизация): любой вошедший пользователь читает чужие заказы, перебирая id. Это IDOR — Broken Access Control, A01 в OWASP Top 10.
- Проверять владение на сервере в каждом запросе
- Лучше — прямо в запросе:
WHERE id = :id AND user_id = :current - UUID вместо чисел только затрудняет перебор, но не защищает: ссылки утекают
А ещё Запрет по умолчанию: новый эндпоинт закрыт, пока не описано правило доступа
Подробно
Уязвимость. GET /orders/1001 возвращает заказ, если пользователь вошёл. Пользователь меняет число на 1002 — и видит чужой заказ с адресом и телефоном. Это небезопасная прямая ссылка на объект (IDOR) — самый частый вид нарушения контроля доступа, первое место в OWASP Top 10.
Исправление:
- проверка владения в каждом запросе на сервере — не в интерфейсе, не скрытием кнопки;
- в выборке из базы:
SELECT ... WHERE id = :id AND owner_id = :user— тогда чужая строка просто не найдётся, и забыть проверку сложнее, чем в отдельномif; - для сложных правил (роли, организации, общие документы) — централизованный слой авторизации (политики, ABAC, OPA), а не проверки, разбросанные по контроллерам;
- ответ на чужой ресурс — обычно 404, а не 403: не подтверждать существование.
Чем не защититься: UUID вместо последовательных id уменьшает перебор, но ссылки попадают в логи, письма, историю браузера; проверка на клиенте; «секретность» URL.
Профилактика: запрет по умолчанию, тесты на доступ к чужим ресурсам для каждого эндпоинта, автоматические сканеры (два пользователя, перекрёстные запросы).
Что хотят услышать
- Различие аутентификации и авторизации.
- Название уязвимости и её место в OWASP.
- Проверка владения на сервере, лучше в запросе к базе.
- Почему UUID не решение; запрет по умолчанию.
Частые ошибки
- Считать неугадываемые id защитой.
- Проверять доступ только в интерфейсе.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Ничего: аутентификации достаточно, раз идентификаторы неугадываемые
- ✗Проблема только в последовательных идентификаторах; переход на UUID полностью её решит
- ✗Нужно перенести проверку прав на клиент, чтобы разгрузить сервер и упростить код
- ✓Нет проверки владения: перебор id выдаст чужие заказы
Что спросят дальше
- Чем 401 отличается от 403?
- Почему запрет по умолчанию безопаснее перечисления запретов?
Разбор темы
- Безопасность приложения: OWASP, доступ и секреты
OWASP Top 10 в редакции 2025, разница аутентификации и авторизации, ловушки JWT против сессий, хранение паролей и секретов, безопасность цепочки поставок.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.