CAPTCHA є — але нічого не захищає

Багато власників сайтів додають CAPTCHA до контактної форми, бачать маленький значок або прапорець і вважають проблему спаму вирішеною. А сміття продовжує надходити. Часто сама CAPTCHA справна — вона просто не під’єднана ні до чого, що могло б зупинити бота. Ця стаття розглядає типові способи, якими reCAPTCHA, hCaptcha й Cloudflare Turnstile перетворюються на декорацію, та пояснює, як перевірити власні форми.

Де насправді відбувається захист

Усі три сервіси працюють за одним принципом. Скрипт у браузері виконує свої перевірки й передає формі токен — короткий рядок зі значенням «цей відвідувач пройшов перевірку». Токен разом із надісланою формою потрапляє на Ваш сервер. Лише там ухвалюється справжнє рішення: Ваш сервер надсилає токен разом із секретним ключем постачальнику й отримує відповідь — успіх або невдача, а для reCAPTCHA v3 також оцінку. Якщо будь-яка ланка цього ланцюжка відсутня, віджет усе одно виглядає цілком нормально, але бот, який надсилає дані прямо до обробника форми, проходить безперешкодно.

Тестовий ключ, який пропускає все

Google, hCaptcha та Cloudflare публікують спеціальні тестові ключі, щоб розробники могли виконувати автоматизовані тести без розв’язування головоломок. Із відповідним тестовим секретом перевірка завжди успішна — у цьому й полягає їхня мета. Їх призначено для локальних і тестових середовищ, але вони регулярно переживають перехід на робочий сайт: розробник вставляє їх під час створення, сайт запускається, а ніхто їх не замінює. reCAPTCHA принаймні показує у віджеті повідомлення, що він лише для тестування, але за невидимого налаштування на нього майже ніхто не дивиться. Якщо на робочому сайті є і тестовий ключ сайту, і тестовий секрет, кожне надсилання проходить незалежно від того, походить воно від людини чи бота; якщо тестовим є лише ключ сайту, перевірка натомість не вдається й справжні повідомлення можуть відхилятися.

Токен, якого ніхто не перевіряє

Другий класичний випадок — сервер, який ніколи не звертається до постачальника. Віджет працює, токен створюється й надсилається, а потім обробник форми просто його ігнорує. Типові джерела — власноруч написані форми, скопійовані фрагменти лише для браузерної частини та незавершені налаштування плагіна. Близький випадок: сервер таки викликає сервіс перевірки, але перевіряє лише успішність запиту, а не зміст відповіді. Або поріг оцінки reCAPTCHA v3 встановлено на 0, що приймає будь-яку оцінку сервісу. Деякі обробники також працюють за принципом «дозволити в разі помилки»: якщо токена немає або перевірка не вдалася, вони все одно приймають повідомлення, а бот просто не додає токен.

Коли віджет насправді не завантажується

Інші помилки налаштування ламають браузерну частину. Якщо ключ сайту не зареєстровано для домену — типово після переходу з тестового середовища на робоче, зміни домену або появи нового піддомену, — постачальник відмовляється видавати токени й показує помилку у віджеті чи консолі браузера. Після зміни теми або оновлення плагіна розмітка віджета може залишатися на сторінці, тоді як скрипт, що оживляє її, уже відсутній. Інструмент згоди на cookie може мати такий самий ефект, якщо блокує скрипт CAPTCHA до згоди відвідувача. Подальше залежить від сервера: якщо він вимагає дійсний токен, справжні відвідувачі більше не можуть надсилати повідомлення й ніхто не помічає втрачених звернень; якщо не вимагає — боти проходять вільно.

Ще два випадки легко не помітити. У reCAPTCHA v3 значок у кутку показує лише те, що скрипт завантажено десь на сторінці, можливо темою або іншим плагіном, тоді як інтеграцію в самому плагіні форм вимкнено. А плагіни кешування можуть зберігати сторінку разом із токеном, вбудованим у HTML. Токени CAPTCHA дійсні лише кілька хвилин і можуть перевірятися лише один раз, тому кешований токен не працює для справжніх відвідувачів; спокусливе «виправлення» шляхом вимкнення перевірки непомітно прибирає захист.

Коротка самоперевірка

1. 1Відкрийте сторінку форми в приватному вікні, відкрийте інструменти розробника браузера й пошукайте в консолі помилки скрипта CAPTCHA.
2. 2Переконайтеся, що віджет справді з’являється — до й після прийняття банера cookie — та що форму неможливо надіслати за його відсутності.
3. 3В адміністративній консолі постачальника перевірте, чи зазначено для ключа сайту Ваш робочий домен (разом із варіантами на кшталт www) і чи відповідають йому ключі у Вашому плагіні форм або коді, а не ключі з документації чи тестового середовища.
4. 4У налаштуваннях плагіна форм переконайтеся, що інтеграцію CAPTCHA ввімкнено саме для цієї форми; для reCAPTCHA v3 перевірте, що поріг оцінки вищий за 0.
5. 5Якщо Ви маєте доступ до коду, знайдіть серверну перевірку й переконайтеся, що вона відхиляє надсилання за негативної відповіді або відсутності токена.
6. 6Виключіть сторінку форми з кешування цілої сторінки або переконайтеся, що токен створюється заново в браузері.
7. 7Надішліть справжнє тестове повідомлення та перевірте його надходження; повторюйте перевірку після змін теми, плагінів або інструмента згоди.

CAPTCHA — один шар, а не весь захист. У поєднанні з полем-пасткою, перевіркою часу й серверною фільтрацією помилка налаштування в одному місці не залишає форму цілком відкритою. Якщо хочете швидко оцінити стан своїх форм, введіть домен на formexposed.com — звіт покаже, чи впорядковані ті частини Вашого налаштування CAPTCHA, які видно ззовні.