Комментарии 2
если в теле запроса к API случайно (или намеренно) изменить заглавную букву в названии параметра, то SBC вернет 403 Forbidden и зафиксирует это как нарушение модели. Все просто и эффективно.
А само API не 403 вернуло бы? Не очень понятно, зачем всё таки такое нужно - что бы защититься от отсутствия корректной валидации запросов на самом сервере? Иметь более простое управление полиси и валидацией разных апи в одном месте? На серверах валидация вообще не делается? Но ведь севисы могут использовать внешние апи между собой тоже и не через sbc. В общем понятно, что элегантное достаточно решение, но цели как то неочевидны, имхо.
Как много слов… Основная задача Application Firewall - отсечь сетевые атаки. Когда идет много запросов нужно быстро и легко их обработать и отсеять. Это достигается за счет «не парсинга» тела запроса. Те вместо того, чтобы разгрузить приложения, вы продублировали логику парсинга тела запроса и вложили кучу денег в CPU.
Я понимаю, что конкретно в вашем случае это возможно слегка сняло нагрузку с приложений, т к они еще более тяжелые. Но в общем случае такой подход не оправдан имхо.
You shall not pass: как мы внедрили строгую валидацию API в нашем SBC