Comments 14
Все интересно, но пример с чипсами непонятен. Откуда взялось 300? количество 5 стоит для id=0, а чипсы это id=1. И тут либо 1 и 100 рублей или -1 и вообще лажа (возврат что-ли?).
Теперь Ок! Спасибо
Я чего-то не догоняю: а не пофиг ли вообще, как там распарсит парсер? Любые входные данные все равно будут проверяться бизнес-логикой. Скажем, в примере с пачкой чипсов возможность ставить отрицательное количество товара (если таковая вообще есть в принципе) будет зависеть как минимум от роли пользователя.
И это со всеми примерами так: не взломав авторизацию, ими не воспользуешься, а если взломать - так они уже и не нужны.
Не совсем так. Исходный json подменить может любой. И если в компании разные службы обслуживаются разными (микро)сервисами, то вполне возможна такая ситуация. Тут уж зависит от уровня квалификации разработчиков.
Могу, но это не совсем корректно. Знаю разработчиков, которые в принципе считают, что проверка входных данных не их забота.
В строке "HTTP-методы GET, POST, UPDATE и DELETE информируют сервер о том, какое действие нужно совершить над данным ресурсом" нужно бы UPDATE изменить на PATCH, ибо нет такого HTTP-метода как UPDATE.
Забавно, что большинство перечисленных тут уязвимостей являются не прямыми ошибками, а способами обойти WAF и подобные технологии. И вот для защиты от них-то и предлагается WAF…
Защищаем API – что важно знать?