Чеклист безопасности перед запуском — 7 проверок за вечер

Вот неприятная правда: как только твоё приложение появляется в интернете, его сразу начинают щупать боты — автоматически, круглосуточно, без злого умысла лично к тебе. Это не повод бояться запуска, а повод закрыть несколько очевидных дыр заранее. Хорошая новость: для первого проекта хватает короткого списка. Пройди эти семь пунктов за вечер — и ты уже не «лёгкая добыча».
1. Ключи — не в коде
Что: все API-ключи, пароли и адреса баз вынеси в переменные окружения, в файл .env. В коде — только process.env.ИМЯ.
Почему: ключ, вписанный в код и попавший в репозиторий, воруют боты за минуты и тратят твои деньги.
Подвох: мало вынести ключ — проверь, что .env указан в .gitignore, иначе он всё равно уедет в репозиторий вместе с кодом.
2. Секреты не утекли в браузер
Что: убедись, что серверные ключи не попадают на фронтенд. Всё, что уходит в браузер, видно любому через «Инспектор».
Почему: новички часто кладут секретный ключ туда, откуда он рендерится на странице. В большинстве фреймворков переменные с префиксом вроде NEXT_PUBLIC_ или VITE_ уходят в браузер специально — туда нельзя класть секреты.
Подвох: открой готовую страницу, нажми «Просмотр кода» и поищи свои ключи. Нашёл — значит, утечка; перенеси вызов на сервер.
3. Доступ к базе закрыт правилами
Что: включи защиту строк (база данных на Supabase — это RLS) и настрой правила: пользователь видит только свои строки.
Почему: без правил публичный ключ позволяет любому прочитать или стереть всю таблицу — чужие заметки, чужие заказы.
Подвох: включённый RLS без единого правила блокирует всё подряд, и кажется, что «база сломалась». Это нормально: добавь правило «строку видит её владелец».
4. Сайт работает по HTTPS
Что: проверь, что адрес начинается с https://, а не http://. Замочек в адресной строке.
Почему: по обычному http данные летят открытым текстом — пароль можно перехватить в публичном Wi-Fi.
Подвох: почти все современные хостинги (Vercel, Netlify) дают HTTPS бесплатно и сами. Просто убедись, что он включён и нет смешанных http-ссылок внутри страницы.
5. Вход сделан не «на коленке»
Что: не храни пароли сам и не пиши свою авторизацию. Возьми готовый сервис входа (Supabase Auth, Auth0, вход через Google).
Почему: безопасно хранить пароли — отдельная наука (хеширование, соль, защита от перебора). Своя самоделка почти наверняка дырявая.
Подвох: даже с готовым сервисом не забудь про сам сброс пароля и подтверждение почты — провайдеры дают это из коробки, но включить надо руками.
6. Ввод пользователя проверяется
Что: не доверяй тому, что присылает пользователь. Проверяй данные на сервере: тип, длину, формат — даже если на форме уже стоит проверка.
Почему: проверка только в браузере обходится за секунду. Через API запрос можно отправить напрямую, минуя твою красивую форму.
Подвох: «проверка на фронте» — это про удобство, а не про безопасность. Настоящая защита всегда на сервере; клиентскую считай подсказкой, а не барьером.
7. Есть лимиты на запросы
Что: поставь ограничение частоты (rate limiting) на тяжёлые и платные действия — вход, отправку форм, вызовы платного ИИ.
Почему: без лимита один скрипт может за ночь сделать миллион запросов — положить сервис или сжечь твой бюджет на ИИ-вызовах.
Подвох: не обязательно строить это самому — у многих хостингов и API-шлюзов rate limiting включается настройкой. Главное — не оставить платные ручки совсем без ограничения.
Это полный список?
Нет — это нижняя планка для первого запуска, а не аудит для банка. Но именно эти семь пунктов закрывают ошибки, на которых обжигаются чаще всего. Сделал их — ты уже безопаснее большинства пет-проектов в сети. Растёт аудитория — будешь добавлять следующие уровни.
Вопрос: меня правда будут атаковать сразу после запуска?
Не «атаковать» персонально, а сканировать автоматически — да, почти сразу. Боты постоянно перебирают новые адреса в поисках открытых ключей и незащищённых баз. Им всё равно, кто ты; они ищут лёгкие двери. Эти семь пунктов как раз про то, чтобы лёгких дверей у тебя не было.
Вопрос: ИИ-агент сам сделает всё безопасно?
Частично. Современные агенты обычно сразу раскладывают ключи по .env и берут готовую авторизацию — это хорошо. Но проверить доступ к базе, лимиты и утечки в браузер всё равно стоит самому: агент пишет «чтобы работало», а не «чтобы было защищено». Этот чеклист — твой способ проверить за ним.
Короткие уроки-истории, симулятор агента и ежедневная практика — в нашем мобильном приложении. Бесплатно.





