Безопасность сайта: сравнение конструкторов, популярных CMS и кастомных решений

За годы работы с сайтами я вывел для себя простое правило: безопасность — это не функция, которую можно «включить» галочкой в админке. Это процесс, который начинается в момент выбора платформы и продолжается весь срок жизни проекта. Уязвимым можно сделать что угодно: и конструктор с закрытой инфраструктурой, если бесконтрольно раздавать доступы к аккаунту, и популярную CMS с десятком плагинов разной степени свежести, и полностью кастомный проект, написанный без код-ревью и тестов на проникновение. Разберёмся, где на практике слабые места и как их не допустить.

Почему безопасность нужно учитывать ещё на этапе выбора платформы

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

На практике безопасность сайта складывается из нескольких слоёв:

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

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

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

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

Самые частые угрозы

• Брутфорс — автоматический подбор пароля к админке. До сих пор работает, особенно если нет ограничений по количеству попыток.
• XSS — внедрение вредоносного скрипта через форму, комментарии, шаблон или расширение. Опасен тем, что может выполняться в браузере администратора.
• SQL-инъекции — попытка добраться до базы данных через уязвимый код. Один неэкранированный запрос — и данные клиентов могут утечь.
• CSRF — принуждение администратора к опасному действию без его ведома, например, через поддельный запрос на перевод средств или смену пароля.
• RCE — удалённое выполнение кода. Самый опасный сценарий, когда атакующий получает доступ на уровне сервера.
• Взлом через плагины и темы — особенно типично для CMS. Достаточно одного расширения от неизвестного разработчика.
• Компрометация аккаунта подрядчика — ситуация, когда доступы выданы слишком широко, а у самого подрядчика пароль утёк или хранится в открытом виде.

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

Сравнение по уровню безопасности: конструкторы, CMS и кастомные сайты

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

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

Конструкторы сайтов: когда это безопасно, а когда нет

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

Плюсы конструкторов с точки зрения безопасности

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

Слабые места конструкторов

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

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

Когда конструктор — хороший выбор

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

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

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

CMS: гибкость есть, но именно здесь чаще всего ломают сайты

Популярные CMS вроде WordPress, Drupal или Joomla страдают не от того, что у них плохое ядро, а от массовости и экосистемы расширений. Исследования неоднократно показывали, что заметная доля уязвимостей связана именно с плагинами и дополнительными компонентами. Я это подтверждаю практикой: приходишь на аудит, а там двадцать активных плагинов, из которых половина неиспользуемых, но не удалённых, а ещё три — от разработчиков с сомнительной репутацией.

Почему CMS чаще атакуют

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

Типовые риски CMS

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

Какие CMS безопаснее на практике

Безопаснее не «самая известная», а та, которую регулярно обновляют и правильно обслуживают. Drupal традиционно считается более строгим по архитектуре, но сложнее в администрировании. WordPress проще и массовее, а значит требует жёсткой дисциплины по плагинам и обновлениям. Joomla находится где-то между ними, но тоже сильно зависит от расширений. Важно понимать: выбор CMS — это только половина дела, вторая половина — процессы эксплуатации.

Что обязательно делать на CMS

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

Кастомная разработка: максимум контроля, но и максимум ответственности

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

Сильные стороны кастома

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

Главные риски кастома

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

Где кастом оправдан

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

Как выбрать безопасный вариант под свою задачу

Если нужен простой сайт

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

Если нужен контентный проект или интернет-магазин

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

Если нужен нестандартный сервис

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

Практический чек-лист безопасности для любого сайта

Этот список полезно пройти ещё до запуска. Я использую его как минимальный порог для любого проекта, который отдаю клиенту или запускаю сам.

• Используется сложный уникальный пароль для админки.
• Включена двухфакторная аутентификация.
• Есть резервные копии по расписанию.
• Понятно, кто и зачем имеет доступ к сайту.
• Удалены лишние плагины, темы и интеграции.
• Обновления не игнорируются неделями.
• На сайте подключён HTTPS.
• Формы защищены от спама и перебора.
• Настроены права доступа по принципу минимальной необходимости.
• Проверено, как восстанавливается сайт из бэкапа.
• Есть план действий на случай взлома.

Пошагово: как оценить безопасность сайта перед запуском

Шаг 1. Посмотреть, что отвечает за обновления

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

Шаг 2. Проверить расширения

Любой лишний модуль — это дополнительный риск. Если он не нужен, его нужно удалить, а не просто отключить. Отключённый плагин всё равно лежит в файловой системе и может быть проэксплуатирован при определённых условиях.

Шаг 3. Оценить доступы

У каждого участника проекта должен быть только тот уровень прав, который нужен для работы. Я часто вижу, как контент-менеджеру выдают права администратора просто потому, что так удобнее. Это прямой путь к проблемам.

Шаг 4. Проверить резервное копирование

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

Шаг 5. Посмотреть на историю поддержки

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

Типовые ошибки, из-за которых сайты взламывают

• установка пиратских тем и модулей;
• одинаковые пароли у всех сотрудников;
• отсутствие 2FA;
• запуск старой версии CMS;
• подключение сомнительных внешних сервисов;
• игнорирование уведомлений об обновлениях;
• хранение резервных копий рядом с основным сайтом;
• выдача лишних прав подрядчикам;
• отсутствие логирования;
• вера в то, что «маленький сайт никому не нужен».

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

Что безопаснее: конструктор, CMS или кастом

Короткий практический вывод, к которому я пришёл на основе десятков проектов:

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

Если смотреть честно, большинство проблем в вебе возникает не из-за «плохой платформы», а из-за плохой эксплуатации. Хорошо настроенная CMS часто безопаснее заброшенного кастомного проекта. А конструктор безопаснее не потому, что он «неуязвим», а потому, что часть ответственности берёт на себя платформа.

Вывод

Выбор между конструктором, CMS и кастомной разработкой нужно делать не только по бюджету и скорости запуска, но и по модели безопасности. Чем больше у вас контроля, тем больше и зона ответственности. Чем меньше контроля, тем сильнее зависимость от платформы, но тем ниже риск ошибок в администрировании.

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

FAQ

Что безопаснее: конструктор или CMS?

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

Почему WordPress часто считают уязвимым?

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

Можно ли сделать кастомный сайт самым безопасным?

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

Какие меры безопасности обязательны для любого сайта?

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

Что важнее всего при выборе платформы?

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