«Поставьте reCAPTCHA на форму» — типичная рекомендация из чеклиста безопасности. Через полгода владелец продукта спрашивает: почему счёт растёт, почему виджет не грузится у части пользователей в РФ, и зачем мы отправляем поведение посетителей в Google. В 2026 году «дорого» у капчи — не только про рубли за тысячу проверок. Это ещё юридические риски, лишний JavaScript, ложные срабатывания и зависимость от чужого SaaS.

Ниже — когда виджет действительно нужен, когда хватает более дешёвого контура, и какие альтернативы reCAPTCHA и Yandex SmartCaptcha мы используем в продуктах OtherCode — в том числе на othercode.ru, где форма заявки защищена локальной проверкой без сторонних скриптов.

Что значит «дорого»

«Дорого» часто наступает раньше, чем кажется: не когда миллион проверок в месяц, а когда юрист просит обновить политику ПДн, DevOps видит 503 от Google в production, а маркетинг теряет 15% лидов из-за невидимой капчи.

Нужна ли капча вообще

Капча — последний рубеж, не замена архитектуре. Перед выбором провайдера ответьте:

1. Какой актив защищаем? Публичная форма «оставить заявку» ≠ регистрация с бонусом ≠ API без авторизации.
2. Какой ущерб от спама? 10 писем в день в CRM — терпимо; 10 000 — уже инцидент.
3. Есть ли аутентификация? Для логина важнее rate limit + MFA, чем капча на каждый ввод пароля.
4. Можно ли отложить контакт? Double opt-in по email/SMS отсекает ботов без виджета.

Если риск низкий — не платите ни деньгами, ни зависимостью. Сначала включите дешёвые слои.

Слои защиты без виджета

Рабочий минимум для корпоративного сайта и формы заявки:

1. Rate limiting

Ограничение запросов по IP (и по fingerprint сессии, если есть) на уровне nginx, API gateway или приложения. Для формы «5 отправок с одного IP за 15 минут» отсекает большую часть скриптового спама.

2. Honeypot

Скрытое поле, которое человек не видит, а бот заполняет. Нулевая стоимость, нулевой UX-штраф. В OtherCode поле _hp вынесено за экран и помечено aria-hidden.

3. Время жизни и «слишком быстрая» отправка

Форма, отправленная через 200 мс после загрузки страницы, — почти наверняка бот. Сервер выдаёт одноразовый challenge при открытии страницы и отклоняет токен, если между выдачей и submit прошло меньше порога (у нас — 2 секунды).

4. Одноразовый подписанный токен

Challenge подписывается HMAC на сервере, содержит nonce и TTL. Повторное использование токена блокируется — защита от replay.

5. Валидация и санитизация на сервере

Капча не спасёт от SQL-инъекций и XSS. Серверная валидация обязательна в любом случае — см. проектирование REST API.

6. Подтверждение канала

Для аккаунтов с ценностью (баланс, данные клиентов) — письмо или SMS-код важнее любой картинки с светофорами.

Браузер                    Ваш backend
   |  GET /api/captcha/challenge
   | ------------------------>  rate limit, выдать signed token
   | <------------------------  { token }
   |
   |  POST /api/contact + token + honeypot
   | ------------------------>  проверить подпись, TTL, nonce,
   |                            honeypot, rate limit, время
   | <------------------------  200 / 429 / 403

Так устроена локальная капча на othercode.ru: без загрузки скриптов Google/Яндекса, без передачи поведения пользователя третьей стороне. Переключатель NEXT_PUBLIC_CAPTCHA_PROVIDER=none отключает проверку в dev; в production без CAPTCHA_SECRET отправка блокируется.

Этого достаточно для типичной B2B-формы с десятками–сотнями заявок в месяц. Для открытой регистрации с бонусами — обычно нет.

Когда виджет всё же нужен

Если боты целенаправленно обходят honeypot (headless Chrome, ручной фарм, LLM-агенты с задержками), подключайте challenge с доказательством «человечности»:

Практика OtherCode: гибрид. Лендинг и «оставить заявку» — локальный контур. Регистрация в продукте заказчика с высоким abuse-потенциалом — SmartCaptcha или Turnstile только на этом endpoint, не на всём сайте.

Как снизить счёт, если остаётесь на Google / Яндексе

1. Не вешайте капчу глобально — только POST на /register, /forgot-password, /contact.
2. Порог score для reCAPTCHA v3 — не ставьте 0.9 «на всякий случай»; калибруйте по логам.
3. Server-side verify всегда — токен с клиента без проверки на backend бесполезен.
4. Кэш «доверенных» сессий — повторная отправка из той же сессии без повторного challenge (осторожно с abuse).
5. Сначала rate limit — часть ботов отсечётся до платной проверки.
6. Мониторинг — график captcha_fail / submit покажет атаку раньше счёта.

Выбор стратегии: таблица решений

Реализация в Next.js (схема)

Типовая структура для App Router:

src/app/api/captcha/challenge/route.ts   — выдача signed token
src/lib/captcha-server.ts                — verify на submit
src/hooks/useCaptchaToken.tsx            — клиент: challenge + honeypot
src/app/api/contact/route.ts             — форма вызывает verifyCaptcha()

Принципы:

• Секрет только на сервере — CAPTCHA_SECRET, не NEXT_PUBLIC_*.
• Провайдер как enum — local | none | smartcaptcha (расширяемо без переписывания форм).
• Единая функция verifyCaptcha() для всех форм — контакты, вакансии, demo-request.
• Логи без ПДн — писать rate_limit, honeypot, expired, не email отправителя.

Подробнее про серверную часть Next.js — в статье про App Router. Про общий контур ИБ — кибербезопасность 2026.

Типичные ошибки

1. Капча только на фронте — бот шлёт POST напрямую в API.
2. Один ключ на dev и prod — утечка из репозитория компрометирует production.
3. Капча вместо rate limit — платите за каждый запрос бота, который можно резать бесплатно.
4. Invisible reCAPTCHA на каждой странице — лишний JS и ложные блокировки SEO-ботов (настройте исключения).
5. Нет fallback — виджет не загрузился → пользователь не может отправить форму. Нужен запасной канал (email, телефон) или деградация с усиленным rate limit.

Чеклист перед сменой провайдера

• Зафиксировать baseline: заявок/день, % спама, стоимость проверок
• Оценить, нужен ли виджет или хватит локального контура
• Проверить политику ПДн и cookie-баннер под нового провайдера
• Вынести verify в один серверный модуль
• Нагрузочно протестировать rate limit (не DDoS-ить себя в prod)
• Заложить метрики: challenge_issued, submit_blocked, submit_ok
• Документировать для команды: когда включать none в staging

Итог

reCAPTCHA и SmartCaptcha — нормальный выбор, когда abuse реален и бюджет на проверки оправдан. Но для большинства корпоративных сайтов и форм «связаться с нами» они избыточны и действительно дороги — в широком смысле: деньги, зависимость, UX, compliance.

Сначала постройте слои: rate limit, honeypot, signed challenge, серверная валидация. Виджет подключайте точечно — на регистрацию и другие high-risk endpoints. Так вы платите провайдеру только за то, что не закрывается бесплатной инженерией.

---

Нужно спроектировать защиту форм, API или миграцию с Google reCAPTCHA? Оставьте заявку — OtherCode внедряет локальный контур и гибридные схемы под 152-ФЗ и ваш трафик.