Как сделать безопасный сайт в 2026: чек-лист для сайта на ИИ

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

Почему у сайтов, собранных с ИИ, дыры повторяются

Модель пишет код под задачу «чтобы работало». Если в задании не сказано про доступы, она соберёт рабочую страницу и оставит настройки по умолчанию: ключ прямо в файле, база открыта на чтение, форма отправляется без проверок. На этапе сборки это удобно, а после публикации уезжает в интернет вместе с сайтом.

Насколько история типичная, видно по платформе Lovable. В базе уязвимостей запись CVE-2025-48757 описывает это так: недостаточные политики Row-Level Security в Lovable до 15 апреля 2025 года позволяли постороннему без авторизации читать и записывать произвольные таблицы базы у сгенерированных сайтов. Уровень критический, оценка 9,3 из 10 (GitHub Advisory Database). Платформа настройки поправила, но сама схема (браузер ходит в базу напрямую, а правила доступа никто не прописал) встречается везде, где сайт собирают быстро.

Практически всё сводится к пяти пунктам:

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

Ключи и токены: что уехало в браузер

Всё, что попало в HTML, CSS и JavaScript сайта, видно любому посетителю: достаточно открыть исходный код страницы. Ключ от платного API, токен телеграм-бота, пароль от базы, строка подключения. Спрятать их в клиентском коде невозможно, можно только не класть туда.

Про это прямо написано в документации сборщика Vite, на котором работает большинство современных ИИ-конструкторов: переменные с префиксом VITE_ попадают в клиентский код после сборки, поэтому ключи API в них хранить нельзя, значения зашиваются в исходники на этапе сборки (документация Vite).

У Supabase, самой частой базы для таких сайтов, два разных ключа. Публикуемый (anon) рассчитан на браузер и работает только в рамках правил доступа. А service_role обходит Row Level Security целиком, ему место только на сервере (документация Supabase). Если ИИ вставил в страницу второй, посетитель получает полный доступ к вашим данным.

Отдельная частая история: сайт отправляет заявки прямо в телеграм-бота из браузера. Тогда токен бота лежит в коде страницы, а Telegram предупреждает, что токен даёт полное управление ботом и хранить его надо надёжно (документация Telegram). Если так уже вышло, откройте @BotFather, командой /token выпустите новый токен, старый после этого перестанет работать.

Порядок проверки простой:

1. Откройте опубликованную страницу и посмотрите её исходный код (Ctrl+U в браузере на Windows, Cmd+Option+U на Mac). Поищите по нему слова key, token, secret, password.
2. Если сайт собран из проекта, поищите те же слова по файлам проекта и по истории Git: удалённая строка остаётся в старых коммитах.
3. Каждый найденный ключ считайте скомпрометированным. Выпустите новый в панели сервиса, старый отзовите.
4. Новый ключ положите туда, куда браузер не заглядывает: в серверную функцию, в переменные окружения хостинга или в настройки самого сервиса.
5. Убедитесь, что файл .env не попал в репозиторий, и добавьте его в .gitignore.

Проверку можно поручить той же нейросети, которая собирала сайт. Промпт, который работает лучше общего «проверь безопасность»:

Проверь проект на секреты, которые попадут в браузер.
Найди в коде и в истории Git строки, похожие на ключи API,
токены ботов, пароли и строки подключения к базе.
Для каждой находки укажи: файл, строку, какой это сервис
и попадёт ли значение в собранный клиентский бандл.
Отдельно перечисли переменные окружения, которые видны из браузера.
Ничего не исправляй, сначала покажи список.

Автоматические проверки тоже бесплатные. У GitHub сканирование секретов работает для публичных репозиториев без оплаты (GitHub Docs). Локально то же самое умеет открытый gitleaks под лицензией MIT: он ищет пароли, ключи и токены в репозиториях и файлах, папка проверяется командой gitleaks dir -v . (gitleaks на GitHub).

По теме: Как сделать сайт одноклассников в 2026: встреча выпускников

Форма заявки: спам и лишние отправки

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

Капча решает основную часть задачи, и подходящие варианты доступны из России. Yandex SmartCaptcha даёт 10 000 проверок в календарный месяц бесплатно, дальше по тарифу (тарифы Yandex Cloud). У Cloudflare Turnstile бесплатный план не ограничен по числу проверок, лимиты стоят на другом: до 20 виджетов и 10 доменов на виджет (Cloudflare).

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

Минимальный набор для любой формы:

• скрытое поле-ловушка: человек его не видит и не заполняет, автоматика заполняет почти всегда;
• ограничение частоты отправок с одного адреса;
• проверка полей на сервере, а не только в браузере (браузерную легко обойти);
• капча, если заявок много или сайт рекламируется;
• чекбокс согласия на обработку данных и ссылка на политику.

Доступы: админка, пароли, двухфакторка

Взлом сайта чаще всего начинается не с кода, а со входа в панель хостинга или в админку. Поэтому доступы стоят выше по важности, чем всё остальное в этой статье.

• Отдельный пароль на панель хостинга, почту домена и репозиторий: одинаковый пароль везде превращает одну утечку в потерю всего.
• Двухфакторная аутентификация в панели хостинга. У Beget, например, вход подтверждается кодом из приложения по TOTP, а коды восстановления предлагают сохранить сразу при подключении (инструкция Beget).
• Никаких учёток по умолчанию: логин admin и пароль вида 123456 подбираются автоматикой в первые же дни.
• Служебные страницы (админка, тестовая версия, страница со списком заявок) закрыты паролем или доступны только по вашему адресу.
• Список тех, у кого есть доступ, пересматривается: FTP-аккаунты подрядчиков и старые ключи надо удалять, а не оставлять «на всякий случай».

Отдельная страница или весь сайт закрывается паролем за несколько минут, способы мы собрали в инструкции про пароль на сайте.

По теме: Как сделать QR-код сайта в 2026: генератор, печать и метки

HTTPS, обновления и чужие скрипты

HTTPS сейчас базовая настройка, а не опция. Бесплатный сертификат Let's Encrypt включается у большинства хостингов в пару кликов. Сертификаты выпускаются на 90 дней и продлеваются автоматически; с 13 мая 2026 доступен профиль на 45 дней, а с 10 февраля 2027 обычный профиль перейдёт на 64 дня (Let's Encrypt). Практический вывод один: автопродление должно быть включено, иначе однажды сайт откроется с предупреждением.

Обновления касаются всего, что вы не писали сами. Для сайта на движке это ядро, тема и плагины. Для сайта, собранного из кода, это библиотеки в package.json: раз в пару месяцев стоит попросить ИИ обновить зависимости и прогнать сайт на работоспособность.

Чужие скрипты требуют отдельного внимания. Каждый подключённый <script src="..."> с постороннего домена выполняется на вашей странице с теми же правами, что и ваш код: он видит формы, куки и содержимое страницы. Разумное правило: на сайте живут только те скрипты, которые вы осознанно выбрали (счётчик, платёжный виджет, карта), и подключены они с официального адреса сервиса. Если ИИ подтянул библиотеку с незнакомого CDN, попросите заменить её на официальный источник или положить файл к себе на хостинг.

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

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

Бэкапы и что делать, если сайт взломали

Резервная копия закрывает почти любой сценарий, включая ваши собственные ошибки. У Timeweb на виртуальном хостинге копии файлов и баз создаются каждую ночь и хранятся 30 дней (справка Timeweb). Похожие механизмы есть у большинства хостингов, но проверить их наличие лучше заранее, а не в момент, когда копия понадобилась.

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

Если признаки взлома всё же появились, паниковать не нужно, порядок действий известный:

1. Смените пароль от панели хостинга и включите двухфакторную аутентификацию, если её не было.
2. Отзовите и перевыпустите все ключи и токены, которые использовал сайт.
3. Разверните последнюю копию, сделанную до появления проблем.
4. Сравните восстановленные файлы с теми, что были на сайте: посторонний код обычно виден как незнакомые файлы или вставки в конце существующих.
5. Обновите движок и библиотеки, закройте служебные страницы паролем.
6. Проверьте список тех, у кого есть доступ: FTP-аккаунты, ключи, приглашённые пользователи. Лишних удалите.

По теме: Запрет сайта: как закрыть доступ и индексацию в 2026

Чек-лист перед публикацией

Пройдите по нему один раз перед тем, как показывать сайт людям, и потом повторяйте после каждого крупного изменения.

• В исходном коде страницы нет ключей, токенов и паролей.
• Файл .env не попал в репозиторий, репозиторий приватный.
• Секретные ключи лежат на сервере или в настройках хостинга, а не в браузерном коде.
• У базы настроены правила доступа: посторонний не может прочитать чужие записи.
• Форма защищена от автоматических отправок и проверяется на сервере.
• Админка и служебные страницы закрыты паролем.
• У панели хостинга включена двухфакторная аутентификация.
• HTTPS работает, автопродление сертификата включено.
• Резервная копия существует и вы знаете, как её развернуть.
• Подключены только те внешние скрипты, которые вы выбрали сами.

Чтобы не проходить список вручную, попросите нейросеть пройти его за вас по коду проекта:

Проверь мой сайт по списку и ответь таблицей: пункт, статус, что править.
1) секреты в клиентском коде,
2) правила доступа к базе,
3) проверка данных формы на сервере и защита от массовых отправок,
4) открытые служебные страницы и админка,
5) внешние скрипты и их источники.
По каждому пункту укажи конкретный файл и строку.
Не меняй код, сначала покажи отчёт.

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

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

Нужен ли платный SSL-сертификат?

Для визитки, лендинга или блога хватает бесплатного Let's Encrypt: замок в адресной строке и шифрование у него ровно те же. Платные сертификаты отличаются проверкой организации и гарантиями удостоверяющего центра, это история для банков и крупных магазинов.

Я нашёл свой ключ в коде. Достаточно удалить строку?

Нет. Ключ мог быть скопирован, пока страница висела в интернете, и вдобавок он остаётся в истории Git. Выпустите новый ключ в панели сервиса, а старый отзовите: только это реально закрывает доступ.

Капчи достаточно, чтобы форму не спамили?

Капча убирает основную массу автоматических отправок, но данные всё равно надо проверять на сервере: длину полей, формат почты и телефона, частоту отправок. Проверка только в браузере обходится за минуту.

Как понять, что с сайтом что-то не так?

Обычные признаки: в исходном коде появились незнакомые ссылки или скрипты, файлы изменились датой, которую вы не помните, сайт иногда перебрасывает на посторонние страницы, хостинг прислал уведомление. В этом случае сначала сделайте копию текущего состояния (она пригодится, чтобы разобраться), потом меняйте доступы и разворачивайте чистую версию.

Нужен ли отдельный специалист по безопасности для маленького сайта?

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