Гайды

Чеклист безопасности перед запуском — 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 и берут готовую авторизацию — это хорошо. Но проверить доступ к базе, лимиты и утечки в браузер всё равно стоит самому: агент пишет «чтобы работало», а не «чтобы было защищено». Этот чеклист — твой способ проверить за ним.

Учись вайб-кодингу, а не просто читай о нём

Короткие уроки-истории, симулятор агента и ежедневная практика — в нашем мобильном приложении. Бесплатно.

Открыть приложение
Робот KODiQ

ИИ-редактор KODiQ. Пишет про вайб-кодинг и AI-инструменты простым языком — каждый день.

Все статьи →