Как защитить приложение от перебора, ботов и мошенников

Ты только что опубликовал своё первое приложение. Ссылка разошлась в чате, знакомые заходят, кто-то оставил комментарий. И вдруг форма обратной связи начинает присылать сотни писем с рекламой казино, в таблице рекордов появляются невозможные значения, а на почту падают уведомления о неудачных попытках входа. Как только приложение становится публичным, к нему подключаются не только живые люди, но и боты, скрипты и те, кто ищет слабое место.

Хорошая новость: для защиты сайта от ботов не нужно быть кибербезопасным экспертом. Достаточно понять несколько базовых принципов и внедрить простые механизмы на уровне форм, базы данных и мониторинга. Ниже разберём угрозы, с которыми сталкивается новичок, пошагово соберём защиту и честно поговорим о том, чего ждать от неё не стоит.

Какие угрозы реальны для приложения новичка

Когда ты слышишь слово «взлом», в голове возникают хакеры, ломающие Пентагон. На практике угрозы для небольшого приложения намного прозаичнее. Чаще всего проблему создают не целенаправленные злоумышленники, а автоматические программы, которые методично перебирают слабые места тысяч сайтов одновременно.

Перебор паролей и кодов (bruteforce)

Bruteforce, или грубая сила, — это метод атаки, при котором программа подбирает пароль или одноразовый код, перебирая варианты одну за другой. Возьмём замок с четырёхзначным кодом: человек будет крутить цифры долго, а робот переберёт все комбинации от 0000 до 9999 за минуты. В интернете такой «робот» — скрипт, который отправляет сотни запросов в минуту на страницу входа или форму восстановления пароля.

Атака бывает двух видов. Первый — полный перебор всех возможных комбинаций. Второй, более распространённый, — атака по словарю, когда скрипт использует списки популярных паролей вроде 123456, password, qwerty и даты рождения. Если пользователь поставил слабый пароль, бот угадает его за секунды.

Особенно опасен перебор одноразовых кодов из SMS или email. Если код из четырёх или шести цифр не ограничен по времени или числу попыток, бот подберёт его до истечения срока действия. Именно поэтому важно не только генерировать случайные коды, но и жёстко ограничивать число попыток их ввода. Подробнее про устройство OTP-авторизации читай в статье Авторизация по OTP, сессии и токены.

Боты-регистрации и фейковые аккаунты

Ещё один массовый источник проблем — автоматические регистрации. Боты создают тысячи аккаунтов со случайными email-адресами, чтобы использовать их для спама, накрутки рейтингов, обхода блокировок или подготовки более серьёзных атак. Для владельца приложения это означает:

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

Если в твоей «Змейке» есть общий рейтинг, боты могут засорить его нереалистичными результатами, и настоящие пользователи перестанут доверять таблице.

Спам через формы

Любая форма, отправляющая данные на сервер, — потенциальный канал для спама. Форма обратной связи, комментарии, отзывы, подписка на рассылку — всё это боты умеют заполнять автоматически. Спам бывает разным: реклама запрещённых товаров, фишинговые ссылки, массовая рассылка одинаковых сообщений, попытки внедрить вредоносный код через поля ввода.

Даже безобидный спам портит репутацию приложения, отвлекает от реальных сообщений и может привести к блокировке почтового сервера, если с твоего домена начинает уходить слишком много мусора.

Нагрузка от скриптов и парсеров

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

Простая защита на уровне формы: rate limiting

Самый эффективный и доступный способ защиты сайта от ботов — ограничить скорость, с которой приложение принимает запросы. Этот приём называется rate limiting, или «ограничение скорости». Смысл простой: если с одного IP-адреса или аккаунта приходит слишком много действий за короткое время, сервер отклоняет лишние запросы.

Как работает rate limiting

Rate limiting считает, сколько раз пользователь обратился к функции за минуту или час, и если лимит превышен, возвращает ошибку или просит подождать.

Типичные лимиты:

• не более 5 попыток ввода пароля за 15 минут;
• не более 3 запросов на отправку OTP-кода в час;
• не более 10 комментариев в минуту;
• не более 50 запросов к API в минуту для одного пользователя.

Важно, чтобы лимиты были разумными. Слишком жёсткие — мешают пользователям, слишком мягкие — не замечают боты.

Ограничение по IP и по аккаунту

IP-адрес — это сетевой адрес устройства, с которого пришёл запрос. Ограничивать по IP просто, потому что не требуется авторизация. Пример: с одного IP не более 20 попыток входа в час. Если бот начнёт перебирать пароли, он быстро упрётся в потолок, а реальный пользователь успеет попробовать несколько вариантов.

Но у IP-ограничений есть нюанс: несколько пользователей могут выходить через один IP, например из офиса или публичной Wi-Fi. А злоумышленники используют прокси и ботнеты с тысячами разных IP. Поэтому IP-ограничения — хороший первый уровень, но не единственный.

Если пользователь авторизован или вводит email, считай попытки отдельно для каждого аккаунта. Например: «С этого email можно запросить не более 3 кодов восстановления в час». Комбинированный подход — ограничение и по IP, и по аккаунту — заставляет атакующего обходить два барьера, а легитимный пользователь почти не замечает защиты.

Пример из OTP-авторизации курса

В курсе skillmake авторизация по OTP устроена так: пользователь вводит email, сервер отправляет одноразовый код, пользователь вводит код и получает доступ. Чтобы защитить цепочку, настраивают лимиты:

• с одного IP нельзя запрашивать код чаще, чем раз в минуту;
• на один email нельзя отправлять более 5 кодов в час;
• ввод кода ограничен 3 попытками, после чего код сгорает;
• код действует не более 10 минут.

Такая схема не мешает нормальному пользователю, но делает перебор бессмысленным. Подробнее про построение такой авторизации читай в материале Авторизация по OTP, сессии и токены.

Где ещё применять rate limiting

Кроме входа и OTP, rate limiting нужен везде, где есть форма или действие: регистрация, форма обратной связи, комментарии, сброс пароля, публичное API. В Supabase многие лимиты можно настроить на уровне базы данных или edge-функций. На Vercel, Netlify и других хостингах часто есть встроенные механизмы защиты от DDOS и rate limiting.

CAPTCHA и когда она оправдана

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

Почему CAPTCHA замедляет ботов

CAPTCHA создаёт дополнительный барьер для автоматических скриптов. Бот, который умеет заполнять формы, сталкивается с задачей, которую сложно решить массово и дёшево. Даже если современные нейросети обходят многие виды CAPTCHA, это замедляет атаку и повышает её стоимость.

Почему CAPTCHA ухудшает пользовательский опыт

Главный недостаток CAPTCHA — она раздражает реальных пользователей. Особенно на мобильных устройствах, где приходится тыкать в мелкие картинки, или при плохом интернете, когда виджет долго загружается. Каждый лишний клик — точка трения, на которой пользователь может закрыть страницу. Кроме того, CAPTCHA плохо работает для людей с нарушениями зрения или моторики.

Где ставить CAPTCHA, а где нет

Правило простое: CAPTCHA ставится только на критических точках, где без неё не обойтись. Для новичка это обычно две ситуации:

• регистрация нового аккаунта — чтобы остановить массовое создание фейковых профилей;
• форма обратной связи или комментарии, доступная без авторизации — чтобы срезать поток спама.

Ставить CAPTCHA на каждую страницу или на форму входа для уже зарегистрированных пользователей — плохая идея. Сначала попробуй rate limiting, и только если он не справляется, добавляй CAPTCHA.

Когда обходиться без CAPTCHA

Часто CAPTCHA можно заменить менее навязчивыми механизмами: подтверждение по email или SMS при регистрации, rate limiting, скрытое поле-ловушка для ботов, проверка времени заполнения формы. Если всё же нужна CAPTCHA, для новичка проще всего использовать готовые сервисы: Google reCAPTCHA, Cloudflare Turnstile или hCaptcha. У каждого есть бесплатные лимиты для небольших проектов, актуальные тарифы смотри на официальных сайтах.

Защита на уровне базы данных: RLS-политики Supabase

Даже если бот прошёл через форму, он не должен получить доступ к чужим данным. Здесь на помощь приходит защита на уровне базы данных. В Supabase такой механизм называется RLS — Row Level Security, или безопасность на уровне строк.

Что такое RLS

Вспомни таблицу рекордов в твоей игре. Без RLS любой, кто умеет обращаться к базе данных, может прочитать все строки: и свои, и чужие. С RLS база данных проверяет, кто делает запрос, и разрешает видеть только те строки, которые принадлежат этому пользователю.

Простая аналогия: в подъезде много почтовых ящиков. Без RLS каждый жилец может открыть любой ящик. С RLS у каждого жильца есть ключ только от своего.

Как работают RLS-политики

RLS-политика — это правило, которое говорит базе данных: «разрешить операцию, только если выполняется условие». Например:

• пользователь может читать только свои записи в таблице профилей;
• пользователь может обновлять только свой рекорд в игре;
• анонимный пользователь не может читать таблицу пользователей;
• администратор может видеть и редактировать всё.

Политики пишутся на SQL, но в Supabase есть графический интерфейс, который помогает создавать их без глубоких знаний синтаксиса.

Пример для приложения новичка

Допустим, в «Змейке» есть таблица scores с результатами игроков. Без RLS злоумышленник может написать скрипт, который подставляет чужие идентификаторы и читает или меняет чужие рекорды. С RLS политика выглядит так: «Разрешить SELECT и UPDATE только для строк, где user_id совпадает с ID текущего авторизованного пользователя».

Также важно закрыть доступ к техническим таблицам: таблица пользователей видна только самому пользователю и админу, таблица сессий — только системе аутентификации, таблица логов — только админу. Подробнее про настройку RLS в Supabase разобрано в статье RLS-политики в Supabase.

Мониторинг подозрительной активности

Защита — это не разовая настройка, а процесс. Чтобы понимать, что происходит с приложением, нужно следить за логами и реагировать на аномалии.

Что фиксировать в логах

Логи — это журналы событий, которые ведёт сервер или приложение. Для защиты от ботов важно записывать:

• неудачные попытки входа с указанием IP и времени;
• запросы на отправку OTP-кода или сброс пароля;
• регистрации новых аккаунтов с одного IP;
• подозрительно частые запросы к API;
• попытки обращения к закрытым данным.

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

Алерты при всплеске запросов

Алерт — это уведомление, которое приходит, когда показатель выходит за пределы нормы. Примеры:

• более 10 неудачных попыток входа с одного IP за 5 минут;
• более 100 регистраций за час;
• резкий рост общего числа запросов к API;
• множество ошибок 429 от rate limiting.

Алерты можно настроить через хостинг, Supabase, внешние сервисы мониторинга или простые скрипты. Для новичка важно настроить хотя бы базовые уведомления на email или в Telegram.

Простые инструменты для мониторинга

• Встроенная аналитика хостинга: Vercel Analytics, Netlify Analytics, Cloudflare Insights.
• Supabase Dashboard: показывает запросы к базе данных и ошибки.
• Сторонние сервисы: Sentry для ошибок, UptimeRobot для доступности.

Что делать, если уже атакуют

Иногда защиту настраивают уже после того, как начались проблемы. Это нормально. Главное — действовать по порядку.

Временно усильте rate limiting

Первое, что нужно сделать при активной атаке, — снизить лимиты. Если раньше было 10 попыток входа в минуту, сделай 3. Если 100 запросов к API, сделай 20. Это сразу снизит нагрузку и замедлит атакующего. Чрезмерно жёсткие лимиты могут мешать пользователям, поэтому усиление должно быть временным.

Заблокируйте подозрительные IP

Если видишь, что с одного или нескольких IP идёт массовая активность, заблокируй их на уровне хостинга, CDN или edge-функций. Но помни: злоумышленники часто меняют IP через прокси и VPN, а ботнеты используют тысячи адресов. Блокировка IP — скорее экстренная мера, чем постоянная стратегия.

Обратитесь в поддержку хостинга

Если атака серьёзная — например, DDOS, когда тысячи устройств одновременно ломятся на сайт, — напиши в поддержку хостинга или CDN. Крупные провайдеры имеют инструменты для отражения таких атак. Сообщи время начала, подозрительные IP, нагруженные страницы, ошибки в логах и уже принятые меры.

Честно о пределах защиты

Полной защиты от профессиональных злоумышленников на уровне новичка-соло-разработчика не бывает. Крупные компании тратят миллионы на безопасность и всё равно иногда взламывают. Если кто-то решит атаковать именно твоё приложение целенаправленно, у него, скорее всего, будет больше ресурсов, времени и опыта.

Но цель новичка — не стать непробиваемой крепостью, а отсечь массовых автоматических ботов. Такие боты ищут лёгкую добычу: открытую регистрацию без лимитов, форму без защиты, базу данных без RLS. Если твоё приложение чуть сложнее, боты пойдут дальше.

Что реально защищает новичок

• Rate limiting снимает большинство атак перебора.
• CAPTCHA на критических точках срезает массовые регистрации и спам.
• RLS-политики не дают прочитать или изменить чужие данные.
• Мониторинг позволяет заметить атаку на ранней стадии.
• Правильное хранение секретов и токенов закрывает ещё один важный вектор. Про это рассказано в статье Хранение секретов и токенов.

Чего не ждать

• Ты не сможешь отразить крупную DDOS-атаку без помощи хостинга или CDN.
• Ты не защитишься от целенаправленного взлома профессионалом.
• Ты не обезопасишь пользователей, которые сами ставят пароли вроде 123456.
• Ты не заменишь полноценный аудит безопасности базовыми настройками.

Это не повод отчаиваться, а повод расставить приоритеты: сделать основное и помнить, что безопасность — это процесс.

Частые вопросы

Можно ли обойтись без защиты, если приложение маленькое?

Теоретически можно, но рискованно. Боты не смотрят на размер приложения — они обходят тысячи сайтов и атакуют любые слабые места. Даже небольшая форма обратной связи может превратиться в источник спама, а открытая база данных — в утечку. Базовая защита занимает немного времени, но сильно снижает риски.

Rate limiting замедлит обычных пользователей?

Если лимиты разумные — нет. Ограничение в 5 попыток входа за 15 минут не мешает человеку, но останавливает перебор. Главное — не ставить лимиты слишком жёсткими и показывать понятное сообщение о том, когда можно попробовать снова.

Нужна ли CAPTCHA, если уже есть rate limiting?

Не всегда. Rate limiting справляется с перебором и многими автоматическими запросами. CAPTCHA стоит добавлять, когда появляется массовый спам или фейковые регистрации, которые rate limiting не останавливает.

Что такое RLS в Supabase и зачем он нужен?

RLS, или Row Level Security, — это механизм, который ограничивает доступ к строкам таблицы. Пользователь видит только свои записи, а чужие — нет. Это важный уровень защиты, потому что проверки в браузере легко обойти, а база данных применяет правила независимо от того, как пришёл запрос. Подробнее в статье RLS-политики в Supabase.

Как понять, что приложение атакуют?

Признаки: резкий рост регистраций, множество неудачных попыток входа с одних IP, всплеск спама в формах, замедление сайта, рост ошибок 429, необычная нагрузка на базу данных. Всё это видно в логах и аналитике хостинга.

Что делать, если боты обходят CAPTCHA?

Если боты обходят CAPTCHA, возможно, используется устаревшая версия. Попробуй перейти на более современный сервис, включить invisible-режим или добавить дополнительные проверки: email-подтверждение, rate limiting, скрытое поле-ловушку, анализ поведения. Также посмотри, с каких IP идут запросы, и временно заблокируй наиболее активные.

Заключение + чек-лист

Защита сайта от ботов — не удел больших команд и крупных бюджетов. Базовые механизмы доступны каждому новичку. Главное — понимать, от чего защищаешься, и применять защиту там, где она реально нужна.

Для приложения на курсе skillmake достаточно нескольких шагов: ограничить запросы через rate limiting, поставить CAPTCHA только на регистрацию и публичные формы, настроить RLS-политики в Supabase, следить за логами и не забывать про безопасное хранение секретов и токенов. Это не сделает приложение неуязвимым, но отсечёт большинство массовых автоматических угроз.

Чек-лист «Защита приложения от ботов»

• Настроен rate limiting на вход, регистрацию, OTP и формы обратной связи.
• Лимиты разумные: не мешают пользователям, но останавливают перебор.
• CAPTCHA добавлена только на критические точки: регистрация и публичные формы.
• В Supabase включён RLS для всех пользовательских таблиц.
• RLS-политики разрешают пользователям видеть и менять только свои данные.
• Ведутся логи неудачных попыток входа, регистраций и ошибок доступа.
• Настроены алерты на всплески запросов и подозрительную активность.
• Секреты и токены хранятся безопасно, не попадают в публичный репозиторий.
• Известно, куда обращаться в поддержку хостинга при серьёзной атаке.