Топ‑10 шагов для защиты сайта от взлома в 2027 году

Короткий ответ

Защита сайта — это процесс, а не одна настройка

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

Актуальная редакция OWASP Top 10:2025 ставит на первые места нарушения контроля доступа, ошибки конфигурации и сбои в цепочке поставок ПО. Это важный сдвиг: защищать только форму входа недостаточно. Нужно знать все компоненты, их владельцев, права, зависимости и сценарий восстановления.

Материал рассчитан на корпоративные сайты, интернет‑магазины, личные кабинеты, WordPress, 1С‑Битрикс, самописные приложения и сервисы с API. Конкретные команды и названия панелей отличаются, но модель защиты одна.

Контекст

От чего реально защищаться в 2027 году

По данным ENISA Threat Landscape 2025, фишинг оставался основным наблюдаемым путём первоначального проникновения, а эксплуатация уязвимостей — следующим крупным вектором. DDoS доминировал среди зарегистрированных типов инцидентов. Эти цифры нельзя механически переносить на любой отдельный сайт, но приоритеты они показывают верно.

Нельзя обновить или отключить то, о чём команда не знает. Начните с реестра активов: домены и поддомены, публичные IP, DNS, серверы, CDN, панели управления, почта, базы данных, объектные хранилища, репозитории, CI/CD, API, боты, сторонние виджеты, аналитика, резервные копии и AI‑провайдеры.

Минимальная карточка каждого актива

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

После инвентаризации проверьте внешний контур глазами неизвестного пользователя: не опубликованы ли тестовые поддомены, панели, старые API, каталоги с резервными копиями, отладочные страницы, Swagger с приватными методами, Git‑метаданные и сервисы, которые давно не используются.

Практическое правило: у каждого публичного адреса должна быть понятная причина существования. Если причину и владельца назвать нельзя — актив нужно изолировать или снять с публикации после проверки зависимостей.

Обновлять нужно не только CMS. В цепочку входят операционная система, веб‑сервер, PHP/Node/Python/Java, база данных, панель хостинга, плагины, темы, библиотеки фронтенда, контейнеры, GitHub Actions или другие CI‑модули. OWASP в 2025 году выделил сбои цепочки поставок ПО в отдельную категорию Top 10.

Как расставлять приоритет

1. Уязвимость уже эксплуатируется. Сверяйте критичные компоненты с каталогом CISA KEV и сообщениями производителя.
2. Компонент смотрит в интернет. Панель, VPN, почтовый шлюз и CMS опаснее внутреннего тестового инструмента.
3. Есть путь к данным или администрированию. Оценка CVSS важна, но бизнес‑контекст важнее.
4. Нет исправления. Ограничьте доступ, отключите функцию, добавьте сетевую фильтрацию и усиленный мониторинг до выхода патча.

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

Для собственной разработки используйте подход NIST SSDF: требования безопасности до разработки, защита среды сборки, анализ изменений, проверяемые релизы и работа с первопричинами найденных дефектов.

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

NIST отмечает, что passkeys устойчивы к обычному фишингу, а CISA рекомендует фишинг‑устойчивую MFA прежде всего для привилегированных аккаунтов. Не используйте общую учётную запись admin на всю команду: она уничтожает персональную ответственность и усложняет расследование.

Проверьте отдельно

• регистратор домена и DNS;
• корпоративную почту и резервные адреса;
• панель хостинга, облако и CDN;
• Git, CI/CD, контейнерный реестр;
• платёжный кабинет, аналитику и рекламные аккаунты.

Скрытая кнопка в интерфейсе не является защитой. Клиентский JavaScript, мобильное приложение и URL контролирует пользователь; окончательное решение всегда принимает сервер. Для каждой операции ответьте на три вопроса: кто пользователь, имеет ли его роль право на действие и принадлежит ли ему конкретный объект.

OWASP API Security называет нарушение авторизации на уровне объектов распространённой проблемой: сервер получает ID заказа, файла или профиля, но не подтверждает право текущего пользователя работать именно с ним.

Базовая модель

• Запрещайте по умолчанию; разрешайте явно по роли и контексту.
• Проверяйте права в каждом обработчике, который получает идентификатор объекта.
• Не полагайтесь на UUID как на замену авторизации.
• Разделяйте пользовательские, операторские и административные API.
• Ограничивайте массовые операции, экспорт и изменение ролей дополнительным подтверждением.
• Пишите негативные тесты: «пользователь A не видит объект B», «менеджер не вызывает admin‑метод».

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

Ошибки конфигурации появляются на стыке компонентов: приложение безопасно само по себе, но хранилище открыто; сервер исправлен, но debug‑страница показывает переменные окружения; HTTPS включён, но cookie уходит без флага Secure.

Что проверить

• Секреты находятся в менеджере секретов или защищённых переменных окружения, а не в Git, JavaScript, образах и резервных копиях без шифрования.
• Продакшен не показывает стек ошибок, SQL, пути файлов и конфигурацию.
• Каталоги, листинг, временные файлы, дампы и логи недоступны из веба.
• База данных и административные сервисы не опубликованы напрямую без необходимости.
• CORS разрешает только нужные источники и методы; wildcard не сочетается с учётными данными.
• TLS настроен современно, сертификат автоматически продлевается, HTTP переводится на HTTPS.

Заголовки браузерной защиты

Для большинства сайтов полезны HSTS, запрет MIME‑sniffing, политика referrer, ограничения возможностей браузера и Content Security Policy. Но CSP нельзя копировать вслепую: сначала соберите реальные источники скриптов, стилей, шрифтов и кадров в режиме отчётов, затем ужесточайте политику.

Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Перед includeSubDomains убедитесь, что все поддомены действительно работают по HTTPS. Перед preload проверьте долгосрочные последствия: отменить его мгновенно нельзя.

Любые данные извне считаются недоверенными: поля формы, JSON, HTTP‑заголовки, имя файла, SVG, архив, ответ стороннего API и даже текст, который сгенерировала модель. Проверка должна соответствовать месту использования.

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

CDN и WAF снижают нагрузку и отсекают массовый шум, но не знают правил вашего бизнеса. Запрос «получить код подтверждения» может быть технически корректным и одновременно использоваться для SMS‑флуда. Поэтому нужны два слоя: сетевой и прикладной.

• Скрывайте origin‑сервер за CDN там, где это возможно; принимайте к нему трафик только от доверенного прокси.
• Настройте лимиты по IP, пользователю, токену, устройству и дорогой операции, а не один общий порог.
• Ограничьте вход, сброс пароля, отправку кодов, поиск, экспорт, генерацию отчётов и AI‑запросы.
• Добавьте очереди, таймауты, верхние пределы размера и контролируемое ухудшение сервиса.
• Не блокируйте только по User‑Agent: он легко подменяется.
• Капчу используйте риск‑ориентированно, после невидимых сигналов и лимитов, а не как единственную защиту.

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

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

Модель 3–2–1 — хорошая отправная точка

• не менее трёх экземпляров данных;
• на двух независимых типах или системах хранения;
• одна копия изолирована от основной учётной записи или находится вне площадки.

Сохраняйте не только файлы и базу, но и DNS‑зону, конфигурацию сервера, переменные, список зависимостей, инфраструктурный код и инструкции. Определите RPO — сколько данных допустимо потерять, и RTO — за какое время сервис должен вернуться.

Без журналов владелец замечает взлом по жалобе клиента или предупреждению поисковика. Логи нужны не «для галочки», а для ответа на вопросы: кто вошёл, что изменил, какие данные запросил, откуда пришёл и что происходило рядом по времени.

События, на которые стоит поставить оповещения

• вход администратора с нового устройства или региона;
• серия неудачных входов, сбросов пароля или MFA;
• создание администратора, изменение роли, ключа API, DNS или платёжных реквизитов;
• необычный экспорт, скачивание большого объёма данных, всплеск 4xx/5xx;
• изменение системных файлов, конфигурации, задач cron и плагинов;
• отключение логирования, антивируса, WAF или резервного копирования;
• аномальный расход AI‑токенов, вызовов API, SMS или почты.

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

Первые действия при подозрении

1. Сохранить доказательства и время событий; не уничтожать логи поспешной переустановкой.
2. Изолировать скомпрометированный узел или ключ, не расширяя простой без необходимости.
3. Отозвать активные сессии и секреты по приоритету, начиная с домена, почты, облака и CI/CD.
4. Определить точку входа и масштаб: какие системы и данные затронуты.
5. Восстановить из доверенной основы, закрыть первопричину, усилить наблюдение.
6. Выполнить юридические и договорные обязанности по уведомлению, если они применимы.

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

OWASP Top 10 for LLM Applications 2025 отдельно рассматривает prompt injection, утечку чувствительных данных, цепочку поставок моделей, отравление данных, небезопасную обработку вывода, избыточную агентность, слабости векторов и embeddings, дезинформацию и неограниченное потребление ресурсов.

Модель может предложить действие. Право на действие, проверку параметров и окончательное исполнение должен контролировать обычный детерминированный код.

Безопасность каждого релиза

Добавьте короткий threat‑review к изменениям: новые данные, роли, внешние запросы, загрузки, библиотеки, секреты, AI‑инструменты. Автоматизируйте SAST, проверку зависимостей и секретов, но не путайте отсутствие предупреждений с отсутствием риска. Бизнес‑логику и права по‑прежнему проверяет человек и тесты.

План внедрения

Что сделать за 24 часа, 7 дней и 30 дней

По типу сайта

Особые точки контроля

WordPress и другие CMS

Удалите неиспользуемые темы и плагины, запретите редактор файлов из админки, ограничьте XML‑RPC если он не нужен, защитите резервные копии, обновляйте PHP и не ставьте расширения из случайных архивов. Не полагайтесь на «переименованный URL админки» как на основную защиту.

1С‑Битрикс

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

Интернет‑магазин и личный кабинет

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

Статический сайт

Риск серверного кода ниже, но остаются домен, DNS, CDN, репозиторий, CI/CD, формы и сторонние скрипты. Компрометация аналитики или tag manager может изменить каждую страницу без правки исходников.

Антипаттерны

Пять ложных ощущений безопасности

1. «У нас есть SSL». Он шифрует канал, но не исправляет права и код.
2. «Сайт маленький, никому не нужен». Массовые боты не оценивают известность бренда.
3. «Поставили WAF — закрыли вопрос». WAF не знает владельца заказа и законность бизнес‑операции.
4. «Есть ежедневный бэкап». Без независимости и теста восстановления это предположение.
5. «Нейросеть проверила код». Автоматический анализ помогает, но может пропустить контекстную ошибку и предложить уязвимое исправление.

Дальше

Проверьте соседние риски