Когда WAF - не помощник
Наткнулся на ситуацию, когда митигация эксплуатации API-метода была бы возможна при блокировке POST-запроса по правилу "если тело запроса более n-байт". Но, используемый WAF в такое не умеет (вендор подтвердил, завел задачку на подумать о такой функции). Представьте: на сайте можно выбрать 3 из 5 категорий кэшбека. Но, ограничение проверяется лишь на фронте. Ничего не мешает обратиться к методу напрямую, указав все 5 параметров в теле POST-запроса:

{
 "CODE_1": "1",
 "CODE_2": "1",
 "CODE_3": "1",
 "CODE_4": "1",
 "CODE_5": "1",
 }

Где разный CODE - последовательность символов (одинаковой длины), которая означает один из кэшбеков (красота, аптеки, рестораны и т.д.). Для митигации (пока разработчики исправляют уязвимость) можно было бы прикинуть максимальное количество байт примерно до (чтоб был небольшой люфт по байтам: чуть более 3-х запросов, но, длина из 4 параметров уже точно не попадала):

{
 "CODE_1": "1",
 "CODE_2": "1",
 "CODE_3": "1",
 "CODE_4":
 }

Как оказалось, подобного правила нет в различных WAF (поспрашивал коллег, почитал документацию некоторых популярных WAF). Правда, тут нужно быть внимательным: иногда представители вендора\интегратора ошибочно считают, что у них это есть. Но, в процессе обсуждения выясняется, что речь идёт о другом. О максимальном размере тела POST-запроса, общим для всех методов (защита от DoS). Либо речь идёт о составлении описания правила, где блокируются запросы, не попадающие под описание правила. Но, в данном случае все 5 параметров в запросе корректны (согласно swagger-схеме). Интересно: какие из существующих WAF уже сейчас умеют в подобные правила (максимальный размер тела запроса для конкретного метода)?