Вот пример интересного IDOR В примерах к IDOR часто описывают что-то типа GET /api/v1/user/1/document/1. Тут всё логично: мы, конечно, попробуем перебрать чужие документы. Но что, если на GET запрос возвращается ошибка доступа? Это не повод отчаиваться. Не забываем про CRUD — даже если в интерфейсе нет красивых кнопочек, возможно, на сервере есть обработчик, и, что важнее, он может не проверять права доступа. Если ни один из очевидных методов не сработал, стоит изучить сервис и найти методы, связанные с этой сущностью. Вот прекрасный пример: https://hackerone.com/reports/2950536 1. Прогнозирование ID В современных приложениях всё реже встречаются целочисленные идентификаторы, но это не приговор. Важно убедиться, что идентификатор действительно непредсказуемый. Вот тут автор приводит ссылку на методологию генерации ID в Salesforce: https://blog.hypn.za.net/2022/11/12/Hacking-Salesforce-backed-WebApps/ 2. Эксплуатация уязвимого контроллера На портале есть уязвимый Apex-контроллер с функцией cloneAttachment. Эта функция предназначена для копирования вложений, но не проверяет должным образом права доступа. Злоумышленник, используя предсказанный ID чужого вложения и свой собственный ID, отправляет запрос к этому контроллеру. В результате контроллер создает копию чужого защищенного файла, но привязывает её к учетной записи злоумышленника. После того как копия файла оказалась привязана к аккаунту злоумышленника, он может скачать её через стандартный механизм, так как теперь формально является её владельцем.