Как защитить сайт от взлома после сборки с ИИ

В журнале сервера видны попытки открыть /.env и /.git/config. Проверьте версии зависимостей, хранение ключей, открытые порты и права администратора до публикации. Были попытки взлома, поэтому у меня в проекте есть обязательный порядок проверок. Нейросеть может написать рабочий код и пропустить защиту; ответственность за запуск остаётся у владельца.

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

Как проверить зависимости до запуска

Для Node.js проекта начните с проверок, которые не меняют работающий сервер:

npm view next version
npm audit --omit=dev --audit-level=high
git log --all -- .env .env.local

Если последняя команда показывает коммиты с секретом, перевыпустите ключ и проверьте историю сканером gitleaks.

После установки пакетов запустите аудит зависимостей и разберите high и critical находки. Не копируйте старые версии из случайного примера. Смотрите версию в официальном реестре и сверьте установленную с файлом проекта. Обновление требует повторной сборки и проверки сценариев, поскольку новая версия тоже может поменять поведение. В проектах Python аналогично проверяйте зависимости подходящим аудитом. Сам факт успешной сборки не означает отсутствия известных уязвимостей.

Где хранить ключи и пароли

Секреты держите в переменных окружения на сервере. Клиентские переменные, которые попадают в браузер, не подходят для API‑ключей. Не оставляйте пароль по умолчанию в коде и не копируйте файл окружения в общую папку. Добавьте проверку секретов перед коммитом и запретите агенту читать закрытые файлы без задачи. Уже опубликованный ключ нельзя «спрятать» удалением строки: его следует перевыпустить у провайдера.

Как закрыть лишние порты на сервере

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

Как защитить административные маршруты

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

Как это выглядит в работе

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

На экране CRM клиники лечения акне «КОСМЕТ_А» показаны агрегированные данные. Доступ к таким отчётам проверяется в каждом серверном маршруте, даже если ссылка на раздел скрыта из меню.

Какая резервная копия действительно поможет

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

Что делать при подозрительных признаках

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

Что проверить на сервере после сборки сайта

В журналах nginx встречаются массовые запросы к /.env и /.git/config. Это попытки найти секреты и служебные файлы, а не доказательство успешного доступа. После сборки сайта проверьте, что приложение принимает соединения только локально, а наружу доступны нужные порты. Команды ниже выполняет владелец сервера после проверки текущего SSH‑доступа. Если SSH работает на другом порту, сначала разрешите именно его и проверьте вход по ключу во второй сессии.

ss -ltnH | grep -vE '127.0.0.1|::1'
sudo ufw default deny incoming
sudo ufw allow 22,80,443/tcp
sudo ufw enable

Перед ufw enable убедитесь, что правила 22, 80 и 443 соответствуют вашей схеме доступа. Проверка истории секретов и аудит пакетов описаны выше. Для Next.js запускайте next start -H 127.0.0.1, наружный трафик пусть принимает nginx. Docker может публиковать порт в обход правил ufw, поэтому для базы указывайте привязку вроде 127.0.0.1:5432:5432.

В systemd полезны NoNewPrivileges и ограничения файловой системы, но сначала проверьте, куда приложение пишет временные файлы. Копия считается рабочей после пробного восстановления в отдельной среде. Что такое вайб-кодинг и где заканчивается прототип помогает отделить черновик от системы с пользователями и данными. На обучении эту проверку можно пройти на собственном тестовом сайте.

Как проверить итог без опасной правки

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

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

Достаточно ли SSL‑сертификата?

Нет. Он защищает передачу данных, но не заменяет аудит кода, секретов, портов и прав.

Можно ли хранить ключ во фронтенде?

Нет. Всё, что отправлено браузеру, доступно посетителю; используйте серверное хранение.

Как часто проверять пакеты?

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

Зачем копия вне сервера?

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

Что проверять в первую очередь?

Секреты, административные маршруты, открытые порты, зависимости и возможность восстановить данные.

Что сделать дальше

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