CAPTCHA ломается не там, где её рвут, а там, где её не умеют обходить

CAPTCHA ломается не там, где её рвут, а там, где её не умеют обходить

Если смотреть на защиту трезво, CAPTCHA — это не барьер, а фильтр стоимости. Она отсеивает шум, но сыпется, когда у атакующего есть нормальный браузер, живой тайминг и аккуратный поток запросов. Поэтому в реальности решает не сам тип капчи, а то, как она встроена в воронку.

Что обычно выдаёт слабую реализацию:
— капча показана только после нескольких попыток, и до неё можно собрать сигналов больше, чем нужно;
— токен проверяется отдельно от сессии, без привязки к отпечатку и пути пользователя;
— фронт ждёт один сценарий, а API принимает другой, более короткий;
— нет контроля на повторное использование токена и на подозрительные паттерны кликов.

Для арбитража это тоже полезный чек-лист: если капча появляется слишком рано, конверт режется; если слишком поздно — защита просто добавляет трение честным. Рабочая схема обычно одна: сначала мягкая валидация, потом риск-скоринг, и только затем тяжёлая капча. Тогда у тебя не ломается UX и не открывается простой маршрут для ботов.

Есть наблюдение которое стоит проверить: чем больше капча зависит от статического вызова на фронте, тем проще её копировать в чужой сессии. Чем сильнее она завязана на поведение, отпечаток и серверную проверку, тем дороже обход. И для defenders, и для attackers правило одинаковое — не смотреть на виджет, смотреть на связку «клиент, токен, сессия, маршрут».