Як я писав власний Reverse CAPTCHA сервіс, або чому класичні капчі бісять усіх, крім ботів
Привіт, я Андрій, fullstack-розробник.
Останні кілька років я займався різними проєктами — робив конструктори для телеграм-ботів, B2B-системи, CRM, навіть великий HR-додаток. І щоразу, коли я стикався з необхідністю захистити форму або API від спаму, я вставляв ту саму капчу. І щоразу мене це дратувало. Не як розробника — як людину.
Я не знаю, як ви, але мене вже ну дуже дістало шукати на картинках пожежні гідранти. Особливо коли їх там немає. Або коли картинка піксельна. Або коли я клікаю правильно, а мені кажуть «спробуйте ще раз» і дають нову сітку з автобусами.
Це бісить.
А от що бісить ще більше — це коли класична капча, яка мала б зупиняти ботів, насправді не зупиняє сучасних ботів. Сучасному боту вже не обов’язково бути примітивним HTTP-скриптом. Він може працювати через браузер і використовувати vision-моделі для розпізнавання зображень Тобто виходить, що ми мучимо реальних людей, а від ботів цей захист майже не допомагає.
Я вирішив спробувати щось інше.
Спочатку це була просто ідея, а не продукт Чесно кажучи, я не планував робити стартап. Мені просто стало цікаво: а що, якщо перенести навантаження з мозку людини на процесор її пристрою? Що, якщо не питати «хто ти? доведи», а просто перевірити, чи здатен твій комп’ютер виконати криптографічне завдання? І зробити це максимально непомітно?
Тобто людина навіть не знає, що її перевіряють. Бо все відбувається у фоновому режимі.
Ця думка мене зачепила. Я сів і почав писати код.
Так з’явився KineSec.
Як це працює — спрощено Якщо пояснювати без зайвої технічної складності, то логіка така:
Власник сайту додає один скрипт — і все.
Коли користувач заходить на сторінку, віджет починає працювати «під капотом».
Він збирає мінімум даних про середовище і виконує невелике обчислювальне завдання.
Якщо пристрій справляється — формується токен.
Токен автоматично додається в усі форми на сторінці, і користувач навіть не помічає, що щось відбувалося.
Ви просто заходите на сайт, заповнюєте форму і відправляєте. Без світлофорів, без автобусів, без «виберіть всі квадрати».
Звучить ідеально, правда?
От тільки на практиці виявилося, що «просто» — це тільки на папері.
Перша проблема: динамічні форми З першого погляду все просто. Я написав такий код:
Підписуйтеся на наші соцмережі
javascript
const forms = document.querySelectorAll(’form’); forms.forEach(form => { const input = document.createElement(’input’); input.type = ’hidden’; input.name = ’kinesec_token’; input.value = token; form.appendChild(input); }); І воно працювало. На звичайних сайтах.
А потім я вирішив потестити на реальних проєктах, де використовується React. І там форми рендеряться динамічно. Через п’ять секунд після того, як скрипт завантажився, форми ще немає в DOM. А через десять — вона вже є, але мій скрипт про це не знає.
Тобто токен просто не потрапляв у форму. І користувач отримував помилку.
Я сидів і думав: «Ну класно, Андрію, ти зробив захист, який ламає користувацький досвід ще до того, як з’явився спам».
Рішенням став MutationObserver — штука, яка стежить за змінами в DOM. Як тільки на сторінці з’являється нова форма — скрипт одразу додає туди токен.
Це вирішило проблему. Але додало трошки сивини.
Друга проблема: користувач не хоче проходити перевірку двічі Якщо ви думаєте, що користувачі люблять капчу — ви помиляєтесь. Якщо ви думаєте, що вони люблять проходити її двічі за п’ять хвилин — ви дуже помиляєтесь.
Уявіть: людина зайшла на сайт, пройшла перевірку, перейшла на іншу сторінку — і знову бачить той самий віджет. Це бісить. Я би сам пішов з такого сайту.
Тому я додав кешування через localStorage.
Після успішної перевірки токен зберігається на 10 годин. Якщо користувач повертається на сайт або переходить на іншу сторінку — віджет бачить, що є дійсний токен, і навіть не показує себе.
Інтерфейс розблоковується миттєво. Ніяких затримок, ніяких дратівливих вікон.
Але тут важливий нюанс: localStorage — це не про безпеку. Це про зручність. Сервер все одно перевіряє кожен токен незалежно. Якщо хтось спробує підробити кеш — нічого не вийде, бо токен підписаний сервером.
Третя проблема: боти теж не дурні Якщо ви думаєте, що достатньо просто видавати токени і сподіватися, що боти не здогадаються їх підробити — ви помиляєтесь.
Боти теж вчаться. Сучасні парсери — це вже не просто скрипти, які роблять HTTP-запити. Це повноцінні автоматизовані браузери, які вміють виконувати JavaScript, рухати мишку, скролити сторінку — тобто імітувати людину майже ідеально.
Тому однієї «криптографічної задачі» недостатньо.
Я додав кілька рівнів:
JWT з підписом — токен підписується на сервері, і його не можна підробити без секретного ключа. Прив’язка до домену та IP — токен, згенерований для одного сайту, не працює на іншому. Rate limiting — якщо з однієї IP надто багато запитів, сервер починає їх відхиляти. Аналіз поведінки — рух миші, скрол, тапи. Але це, чесно кажучи, палиця з двома кінцями. Чому палиця з двома кінцями? Тому що аналіз поведінки — це еврістика. Вона не дає 100% гарантії. Іноді реальна людина поводиться «як бот» — швидко рухає мишкою або взагалі не рухає (наприклад, на мобільному пристрої). А іноді бот настільки добре імітує поведінку, що його майже не відрізнити.
Тому я не роблю ставку на один «магічний» показник. Я просто додаю кілька шарів захисту, щоб зробити парсинг дорожчим. Не непробивним — просто невигідним.
Найдивніша фіча: Anti-Human Це взагалі вийшло випадково.
Спочатку я думав тільки про те, як захистити сайт від ботів. Але потім я задумався: а бувають ситуації, коли боти бажані, а люди — ні?
І зрозумів, що бувають.
Наприклад, якщо ви робите API для ШІ-агентів або для автоматизованих систем. Ви хочете, щоб ваш сервіс використовували машини, а не люди, які створюють зайве навантаження або просто не є вашою цільовою аудиторією.
Тоді я додав режим Anti-Human. У ньому все працює навпаки: якщо система бачить занадто «людську» поведінку — рух мишки, скрол, кліки — вона блокує запит.
Звучить трохи абсурдно, правда? «Ми блокуємо людей, бо вони поводяться як люди».
Але технічно це просто інший набір правил.
Я не впевнений, що цей режим буде масово використовуватись. Але мені було цікаво його зробити. Як експеримент.
Про що я шкодую, або що б зробив інакше Якщо чесно, я багато чого не передбачив на старті.
Наприклад, я думав, що позиціонування віджета на сторінці — це дрібниця. А виявилося, що це одна з найбільших проблем. Якщо віджет плаває в кутку екрана — він перекриває кнопки на мобільних пристроях. Якщо він блокує екран — це дратує користувачів.
В результаті я зробив так: під час перевірки віджет створює напівпрозорий фон, блокує скрол і центрує себе посередині екрана. А після успішної перевірки — плавно зникає.
Це виглядає акуратно. Але я перероблював це тричі.
Ще я недооцінив складність роботи з чужими сайтами. Коли ти вбудовуєш свій код на чужий сайт — ти не контролюєш нічого. Ти не знаєш, які там стилі, які скрипти вже завантажені, яка версія браузера. Тому доводиться писати код, який працює в будь-яких умовах. І це складно.
Що я виніс із цього досвіду Перше — Vanilla JS це круто. Серйозно. Я звик працювати з React, де все декларативно, але коли пишеш на чистому JavaScript без фреймворків — починаєш краще розуміти, як насправді працює браузер. Це дає глибше розуміння. І віджет важить буквально кілька кілобайт.
Друге — UX важливіший за захист. Якщо ваша система захисту дратує користувачів — вони підуть. І неважливо, наскільки технічно досконалий ваш алгоритм.
Третє — безпека це завжди компроміс. Немає ідеального захисту. Є захист, який достатньо дорого обійти. І це нормально.
Четверте — не бійтесь експериментувати. Ідея Anti-Human може здатися безглуздою, але вона народилася з реальної потреби, яку я помітив. Можливо, вона не стане мейнстрімом, але вона розширила моє розуміння того, як взагалі можна будувати системи захисту.
Що далі Зараз KineSec працює на кількох продакшн-сайтах. Я збираю статистику, дивлюся, як поводяться користувачі, і думаю, що ще можна покращити.
У планах:
Додати WebSocket-аналітику в реальному часі. Розширити типи криптографічних завдань. Спробувати використовувати WebGL для додаткової перевірки. Якщо вам цікаво спробувати або потестувати мій захист — KineSec — Reverse CAPTCHA відкритий для реєстрацій: kinesec.recvik.com.ua
Але головне — я хочу почути думку інших розробників.
Тому, якщо ви теж стикалися з проблемою захисту від ботів або маєте досвід із власними CAPTCHA-рішеннями — пишіть у коментарях.
Як ви зараз захищаєте свої форми? Чи використовуєте старі добрі капчі з картинками? Чи вже перейшли на щось нове?
Обговоримо. Буду радий подискутувати.