Безопасность сайта: чек-лист и лучшие практики

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

Для бизнеса в Украине к этому добавляется еще одна реальность: DDoS-атаки. С 2022 года украинские сайты, от госсервисов до медиа и интернет-магазинов, регулярно оказываются под нагрузкой, которую создают намеренно. Поэтому защита от DDoS для нас — не теоретическая тема, а часть базовой гигиены.

Хорошая новость в том, что большинство атак можно предотвратить базовой последовательной работой. В статье разбираем, почему безопасность важна для бизнеса, какие угрозы встречаются чаще всего (отдельно про DDoS), даем практический чек-лист, дополнительные требования для интернет-магазинов, правила для WordPress и других CMS, способы проверки и план действий, если сайт взломали. Мы делаем и поддерживаем сайты в рамках разработки корпоративных сайтов и интернет-магазинов, поэтому чек-лист отражает то, что применяем на реальных проектах.

Почему безопасность сайта важна для бизнеса

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

Когда безопасность дает сбой, последствия вполне конкретные:

Простой. Взломанный или перегруженный сайт перестает работать. Для интернет-магазина каждый час простоя — это потерянная выручка, для B2B-компании — потерянные заявки и испорченное первое впечатление.

Утечка данных. Имена, телефоны, email, адреса и история заказов клиентов могут попасть к посторонним. Утечка данных означает прямые расходы (расследование, уведомления, юристы) и косвенные (потерянное доверие, отмененные заказы).

Штрафы. Закон Украины «О защите персональных данных» требует обеспечить защиту персональных данных, а за нарушения предусмотрена ответственность. Если у вас есть клиенты из ЕС, действует GDPR, где самые серьезные нарушения могут стоить до 20 млн евро или 4 % глобального годового оборота.

Вред для SEO. Если Google обнаружит на сайте вредоносный код или фишинг, Google Safe Browsing будет показывать посетителям красное предупреждение в Chrome и других браузерах, а в поиске может появиться пометка, что сайт, возможно, взломан. Трафик обваливается за часы. Взломанные сайты также используют для размещения спам-страниц и ссылок, которые вредят позициям еще долго после очистки.

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

Так что безопасность — это не тема только для IT. Это часть непрерывности бизнеса, как страхование или бухгалтерия.

Самые распространенные угрозы для сайтов

Чтобы защититься, не обязательно понимать механику атак в деталях. Но знание основных категорий объясняет, зачем нужен каждый пункт чек-листа.

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

SQL-инъекции. Нападающий передает через форму или URL специально подготовленные данные, чтобы заставить базу данных выполнить непредусмотренные команды, например прочитать или удалить данные. Современные фреймворки при правильном использовании это блокируют.

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

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

Brute-force. Боты перебирают тысячи паролей на страницах входа, особенно на известных адресах админок.

Вредоносный код. Внедренный в сайт код, который ворует данные, перенаправляет посетителей, рассылает спам или майнит криптовалюту.

Уязвимые плагины. На сайтах с CMS устаревшие или плохо написанные плагины и темы чаще всего становятся входом для нападающих.

Атаки через зависимости. Нападающие компрометируют стороннюю библиотеку или сервис, от которого зависит ваш сайт, и через него получают доступ.

DDoS. Отдельно про угрозу, которая для Украины особенно актуальна. DDoS-атака — это попытка «положить» сайт, засыпав его огромным количеством запросов с тысяч устройств одновременно, пока сервер не перестанет отвечать настоящим посетителям. Это не взлом: данные остаются на месте, но сайт становится недоступным.

Важно отличать DDoS от обычной DoS-атаки. DoS (denial of service) идет из одного источника, и ее относительно легко заблокировать по адресу. DDoS (distributed denial of service) идет с тысяч зараженных компьютеров, роутеров и серверов по всему миру, поэтому блокировка одного адреса не помогает. Именно поэтому от DDoS защищаются на уровне сети, а не только сервера.

Мотивы бывают разные: политика, вымогательство или попытка навредить конкуренту в разгар сезона. Признаки, на которые стоит обратить внимание:

• сайт внезапно становится очень медленным или совсем недоступным, хотя вы ничего не меняли

• в аналитике или логах резкий скачок запросов из необычных стран, с одинаковых подсетей или на одну страницу

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

• запросы ведут себя странно: одинаковый user-agent, ноль времени на странице, сотни обращений к поиску или корзине в секунду

Не каждый всплеск трафика означает атаку. Рассылка, реклама или упоминание в медиа тоже дают всплеск, но такие посетители ведут себя как люди: переходят между страницами, добавляют товары, заполняют формы. Если видите признаки атаки, не пытайтесь «переждать»: включите защиту на уровне WAF и свяжитесь с хостингом. Про саму защиту — ниже, в чек-листе.

Чек-лист безопасности сайта

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

HTTPS и SSL/TLS

Что такое SSL простыми словами? Это технология шифрования соединения между браузером и сайтом. Сегодня ее заменил протокол TLS, так что SSL — скорее историческое название, которое осталось в обиходе. SSL-сертификат — это цифровой документ, который подтверждает, что сайт действительно принадлежит вашему домену, и позволяет установить зашифрованное соединение по HTTPS. Все, что передается, от паролей до данных заказа, шифруется.

Влияет ли SSL-сертификат на продвижение сайта? Google использует HTTPS как сигнал ранжирования, хотя и не самый сильный. Важнее косвенный эффект: без сертификата Chrome помечает сайт как «Не защищено», и часть посетителей уходит, не дочитав страницу. Для интернет-магазина и любых форм это уже не вопрос позиций, а вопрос конверсии.

• Переведите весь сайт на HTTPS, а не только страницы оплаты и входа, и настройте переадресацию с HTTP.

• Используйте современные протоколы: TLS 1.3, где возможно, TLS 1.2 как минимум, отключите устаревшие версии.

• Включите HSTS, чтобы браузеры всегда подключались по HTTPS.

• Автоматизируйте продление сертификата. Бесплатные сертификаты Let's Encrypt и большинство платных можно продлевать автоматически. Это важнее с каждым годом: с марта 2026 года публичные TLS-сертификаты выдаются максимум на 200 дней, в 2027 году срок сократится до 100 дней, а в 2029 — до 47. Ручное продление скоро станет непрактичным.

• Проверьте смешанный контент, когда HTTPS-страница загружает изображения или скрипты по HTTP.

Обновления и зависимости

• Регулярно обновляйте ядро CMS, плагины и темы, устанавливайте патчи безопасности сразу после выхода.

• Держите актуальным серверное ПО: поддерживаемые версии PHP и Node.js, база данных, веб-сервер.

• Проверяйте зависимости. npm audit для JavaScript-проектов и аудит в Composer для PHP показывают известные уязвимости библиотек. Dependabot и похожие сервисы автоматически предлагают обновления.

• Удаляйте ненужные плагины, темы и библиотеки. Даже неиспользуемый компонент остается точкой атаки.

• Тестируйте обновления на тестовой копии перед продакшеном.

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

Доступы и аутентификация

• Включите двухфакторную аутентификацию (2FA) для всех аккаунтов: админка, хостинг, регистратор домена, CMS.

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

• Установите политику паролей: длинные уникальные пароли в менеджере паролей, никаких паролей в чатах и документах.

• Защитите админку: смените стандартные адреса входа, где возможно, ограничьте количество попыток, ограничьте доступ по IP для внутренних инструментов.

• Раз в квартал пересматривайте аккаунты и удаляйте лишние.

Отдельно про фишинг. Многие взломы начинаются не с кода, а с письма «от хостинга» или «от регистратора домена» с просьбой войти на поддельную страницу. С правильным паролем нападающего не остановит ни один файрвол, поэтому 2FA и осведомленность команды так же важны, как технические настройки.

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

Заголовки безопасности

HTTP-заголовки безопасности говорят браузеру, как вести себя с сайтом. Их недорого настроить, а блокируют они целые классы атак.

• Content Security Policy (CSP) определяет, из каких источников браузер может загружать скрипты, стили и изображения. Самая сильная защита от XSS.

• X-Frame-Options (или директива frame-ancestors в CSP) не дает встраивать ваши страницы в чужие сайты для кликджекинга.

• X-Content-Type-Options: nosniff запрещает браузеру «угадывать» тип файлов.

• Добавьте строгие Referrer-Policy и Permissions-Policy для функций браузера, которые сайту не нужны.

Резервные копии и восстановление

• Соблюдайте правило 3–2–1: три копии данных, на двух разных типах носителей, одна копия вне основной инфраструктуры.

• Определите RPO и RTO. RPO (recovery point objective) показывает, сколько данных вы можете позволить себе потерять, например заказы за последний час. RTO (recovery time objective) показывает, сколько времени сайт может не работать. От этих цифр зависит, как часто делать бэкапы и как быстро должно работать восстановление.

• Делайте резервные копии и файлов, и базы данных, автоматически, храните несколько версий, а не только последнюю.

• Храните бэкапы отдельно от основного сервера, чтобы нападающий, который попал на сервер, не мог их удалить.

• Регулярно проводите тестовое восстановление. Бэкап, который ни разу не восстанавливали, — это надежда, а не бэкап.

Для бизнеса в Украине есть еще один аргумент в пользу копии вне основной инфраструктуры: перебои с электроснабжением и связью. Если сайт и все бэкапы лежат в одном дата-центре, любая серьезная авария там заденет и то, и другое. Копия в другом регионе или у другого провайдера стоит недорого, а восстановление из нее занимает часы, а не недели.

WAF, защита от DDoS и мониторинг

• Поставьте перед сайтом WAF (web application firewall). WAF фильтрует вредоносные запросы, блокирует известные шаблоны атак и поглощает большинство DDoS-атак еще до того, как они дойдут до вашего сервера. Самый распространенный вариант для бизнес-сайтов — Cloudflare; также защиту от DDoS предлагают многие хостинг-провайдеры.

• Настройте rate limiting на страницах входа, поиска, форм и API, чтобы останавливать перебор паролей и злоупотребления.

• Понимайте, от чего именно защищаетесь. Одни DDoS-атаки забивают канал связи или сетевое оборудование огромным объемом трафика, другие имитируют обычных посетителей и перегружают «тяжелые» страницы: поиск, фильтры каталога, корзину. Первые останавливает сетевая защита провайдера, вторые требуют правил WAF, лимитов запросов и проверки подозрительных посетителей.

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

• Храните логи доступа и приложения разумное время и следите, чтобы кто-то действительно реагировал на уведомления.

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

Хостинг и настройка сервера

• Для бизнес-сайта выбирайте managed-хостинг или профессионально настроенный сервер. Дешевый виртуальный хостинг с устаревшим ПО ставит вас рядом с «соседями», которых вы не контролируете.

• Регулярно устанавливайте обновления сервера, в том числе операционной системы.

• Настройте правильные права доступа к файлам, чтобы веб-процессы не могли менять код и конфигурацию.

• Используйте изолированные среды: отдельно продакшен, тестовая и среда разработки. Никогда не оставляйте тестовые копии сайта в открытом доступе.

• Отключите сервисы и порты, которыми не пользуетесь.

Сторонние скрипты и подрядчики. Современный бизнес-сайт загружает код из многих мест: аналитика, менеджер тегов, чат, онлайн-запись, рекламные пиксели. Каждый такой скрипт работает с теми же правами, что и ваш код, поэтому взломанный или небрежный поставщик может повлиять на ваших посетителей. Ведите список всех внешних скриптов, убирайте те, которыми никто не пользуется, а критичные библиотеки по возможности подключайте с Subresource Integrity, чтобы браузер отказался от измененного файла.

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

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

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

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

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

Такой порядок сначала закрывает самые распространенные входы: украденные пароли, устаревшее ПО и отсутствие способа вернуться после инцидента. Более сложные пункты, например строгая Content Security Policy или пентест, идут после того, как база стабильна.

Дополнительные требования для интернет-магазинов

Когда сайт принимает оплату и хранит данные клиентов, ставки растут, а вместе с ними и требования.

PCI DSS. Все, кто принимает оплату картами, должны соответствовать стандарту безопасности платежных карт. Актуальная версия — 4.0.1, и все ее требования обязательны с 31 марта 2025 года. Самый простой способ сократить объем требований: никогда не пропускать номера карт через собственные серверы.

Платежные формы провайдера и токенизация. Используйте платежную форму или страницу оплаты провайдера, например LiqPay или WayForPay. Провайдер хранит данные карты, а магазин получает токен. Ваши системы никогда не видят полного номера карты.

3-D Secure. Дополнительное подтверждение оплаты владельцем карты, обычно в банковском приложении, снижает мошенничество.

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

Шифрование. Шифруйте чувствительные данные в базе и в бэкапах, а не только при передаче.

Защита персональных данных. Закон Украины «О защите персональных данных» и GDPR для клиентов из ЕС требуют законного основания обработки, минимизации данных, понятной политики конфиденциальности и надлежащей защиты. Собирайте только то, что нужно для заказов и маркетинга, на который есть согласие. Если вы продаете в ЕС, разберитесь, что такое GDPR и какие обязательства он накладывает, еще до запуска.

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

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

Безопасность WordPress и других CMS

WordPress работает на огромной части сайтов в мире, поэтому это самая атакуемая CMS. Само ядро регулярно обновляют и латают. Большинство взломов WordPress происходят через плагины, темы, слабые пароли и устаревшие установки. Короткий чек-лист:

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

• Автоматические обновления для мелких релизов ядра и патчей безопасности, регулярные обновления плагинов и тем после тестирования.

• Плагин безопасности. Инструменты вроде Wordfence добавляют файрвол, сканирование на вредоносный код и защиту входа на уровне приложения.

• XML-RPC. Отключите, если не используете. Это частая цель для перебора паролей и атак с усилением.

• Редактирование файлов. Отключите встроенный редактор файлов в админке.

• Администраторы. 2FA, никакого стандартного логина «admin», минимум администраторов.

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

«Взломанные» темы и плагины. Пиратские премиум-темы и плагины, которые часто бесплатно раздают на форумах, — один из самых распространенных источников скрытого вредоносного кода на сайтах WordPress. Они выглядят так же, как оригинал, но часто содержат бэкдоры, которые открывают доступ нападающим через недели или месяцы. Экономия на лицензии здесь обычно оборачивается куда более дорогой очисткой сайта. Покупайте у разработчика или пользуйтесь проверенными бесплатными альтернативами из официального репозитория.

Тестирование и аудит безопасности

Безопасность не настраивается один раз. Ее нужно регулярно проверять.

Сканирование уязвимостей. Автоматические сканеры проверяют сайт на известные уязвимости, устаревшее ПО и ошибки конфигурации. Запускайте их минимум раз в месяц и после крупных изменений. OWASP ZAP — бесплатный и распространенный сканер, Burp Suite — стандартный профессиональный инструмент для более глубокого тестирования.

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

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

Что конкретно должно войти в проверку? Минимальный набор: версии CMS, плагинов и серверного ПО, настройки HTTPS и заголовков безопасности, список пользователей и их роли, открытые порты и сервисы, наличие и свежесть бэкапов, публично доступные тестовые копии или служебные файлы, а также формы на сайте, через которые можно передать вредоносные данные. Результат проверки оформляют как список проблем с приоритетами: что исправить немедленно, что в течение месяца, а что запланировать.

Как часто проверять? Практический ритм для большинства бизнес-сайтов: постоянный автоматический мониторинг, ежемесячное сканирование, ежеквартальный пересмотр доступов и ежегодный внешний аудит или пентест. Большинство этих задач входит в регулярную техническую поддержку сайта, о которой мы отдельно пишем в этой серии статей.

Что делать, если сайт взломали

Если подозреваете взлом, действуйте спокойно и по порядку. План реагирования на инциденты, подготовленный заранее, экономит часы, когда они ценнее всего.

1. Подтвердите и изолируйте. Проверьте признаки: предупреждения в браузерах, странные переадресации, неизвестные администраторы, новые файлы, спам-страницы в поиске. Переведите сайт в режим обслуживания или отключите, если он распространяет вредоносный код или «сливает» данные.

2. Сохраните доказательства. Перед очисткой сохраните логи и копию зараженных файлов. Они помогут понять, как нападающий попал внутрь.

3. Смените все пароли. Хостинг, администраторы CMS, база данных, FTP или SSH, регистратор домена, платежный сервис, подключенные сервисы. Включите 2FA там, где ее не было.

4. Найдите точку входа. Устаревший плагин, слабый пароль, утечка учетных данных, уязвимый код. Без устранения причины сайт взломают снова через несколько дней.

5. Очистите или восстановите. Восстановите сайт из бэкапа, сделанного до заражения, и установите все обновления. Если чистого бэкапа нет, специалисты удаляют вредоносный код вручную.

6. Запросите проверку. В Google Search Console просмотрите отчет «Проблемы безопасности» и после очистки отправьте запрос на проверку, чтобы предупреждения исчезли из поиска и браузеров.

7. Уведомите пользователей и CERT-UA. Если пострадали персональные данные, сообщите клиентам и, где этого требует закон, соответствующим органам. О серьезных киберинцидентах, в том числе масштабных DDoS-атаках, стоит сообщить CERT-UA, правительственной команде реагирования на компьютерные чрезвычайные события Украины.

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

Подготовьтесь до того, как что-то случится. Худший момент для поиска паролей и телефонов — это сам инцидент. Держите короткий документ вне сайта и хостинга: кто владелец сайта и кто принимает решения, контакты хостинга, разработчика и регистратора домена, где лежат бэкапы и как их восстановить, шаблон сообщения для клиентов, контакт CERT-UA. Пересматривайте его дважды в год. Команды, у которых есть такая страница, восстанавливают сайт заметно быстрее, потому что никто не тратит время на выяснение, кто что может сделать.

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