Основные угрозы безопасности сайтов и как от них защититься

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

Кто и зачем атакует обычные сайты

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

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

Что атакующий получает от взлома небольшого сайта:

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

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

Карта угроз: 8 сценариев

Оговорка к таблице: в жизни это не 8 изолированных историй. Типичный инцидент — цепочка. Подобрали пароль администратора, поставили закладку, месяц рассылали спам с вашего сервера, поисковик пометил сайт как зараженный, трафик упал. Формально сработали 3 угрозы из списка, а началось все с одного слабого пароля.

Взлом через уязвимости CMS и модулей

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

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

У «1С-Битрикс» есть штатный канал информирования — центр уязвимостей, где вендор публикует сведения о проблемах и закрывающих их обновлениях. Какие уязвимости Битрикса нужно закрыть в первую очередь, мы разбирали по пунктам.

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

Защита:

• Регулярные обновления. CMS, модули, PHP и серверное окружение. По графику, а критические обновления безопасности — сразу после выхода.
• Ревизия модулей. Все, что не используется, удаляется. Выключенный модуль с дырой остается дырой.
• Подписка на уведомления вендора. Чтобы узнавать о критических уязвимостях от производителя, и не из новостей о массовых взломах.

Подбор паролей и кража доступов

Форму входа в админку боты находят автоматически и начинают перебирать пароли по словарям. В словарях не только «123456» и «qwerty»: туда попадают миллионы реальных паролей из прошлых утечек. Отдельная техника — credential stuffing: если ваш пароль утек из какого-то стороннего сервиса, его попробуют на всех ваших ресурсах, включая админку сайта, почту и хостинг.

Второй канал — кража доступов с компьютеров. Стилер, пойманный сотрудником или подрядчиком вместе с «бесплатной» программой, выгружает сохраненные пароли из браузера и FTP-клиента. С точки зрения сайта такой вход неотличим от легального: правильный логин, правильный пароль, никаких следов взлома.

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

Защита:

• Уникальные длинные пароли для каждого сервиса и менеджер паролей, чтобы их не запоминать.
• Двухфакторная аутентификация везде, где она поддерживается: хостинг, почта, админка.
• Ревизия учеток раз в квартал: у кого есть доступ, зачем, когда использовался в последний раз. Ушел человек или закончился проект — доступ закрывается в тот же день.
• Ограничение входа в админку по IP-адресам или через VPN, если такой режим работы возможен.

Инъекции и XSS: атаки через формы и параметры

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

XSS устроен зеркально: чужой код внедряется в страницу, которую сайт показывает другим людям. Классическая цель — сессия администратора: зашел в админку посмотреть «странный заказ», а внедренный в заказ скрипт уже увел ключ доступа.

Насколько это живая проблема, видно по OWASP Top 10 — отраслевому рейтингу главных рисков веб-приложений. В редакции 2025 года инъекции стоят на 5 месте, а нарушения контроля доступа возглавляют список 4-е издание подряд. Категории десятилетней давности не уходят из топа: их продолжают находить в реальных приложениях.

В типовых CMS ядро от инъекций защищено давно. Дыры почти всегда появляются в доработках: самописный фильтр каталога, «быстрая» интеграция, форма, которую делали в последний вечер перед запуском. Код, написанный мимо штатных API системы, — первое место, куда смотрит пентестер. И бот тоже.

Защита: параметризованные запросы и штатные механизмы CMS вместо ручной склейки SQL, экранирование всего, что выводится на страницу, и WAF или проактивный фильтр, который режет типовые векторы даже при наличии ошибки в коде.

Вредоносный код: что закладка делает на сайте

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

Типовые сценарии:

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

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

Защита — это на 80% скорость обнаружения: контроль целостности файлов, регулярный запуск штатных сканеров CMS, внешний мониторинг сайта в панелях Вебмастера и Search Console. И резервные копии на отдельной площадке, потому что лечение зараженного сайта почти всегда начинается с отката к чистой версии.

DDoS: когда сайт кладут количеством запросов

Механика DDoS не требует ни уязвимостей, ни паролей. Тысячи зараженных устройств по команде обращаются к сайту одновременно, сервер исчерпывает ресурсы и перестает отвечать всем, включая настоящих клиентов. Сайт не взломан. Он просто недоступен.

Масштаб проблемы в 2026 году хорошо виден по данным Роскомнадзора: в феврале и марте ведомство зафиксировало кратный рост числа DDoS-атак на защищаемые ресурсы. Обычно система фиксирует около 350 атак в неделю, в пиковую неделю конца февраля их было 949. Самая продолжительная атака марта шла непрерывно 113 ч. 22 мин. — более 4,5 суток.

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

Защита: базовый анти-DDoS сейчас входит в тарифы многих хостингов и CDN-сервисов, и для начала стоит выяснить, что уже включено в ваш тариф. Агрессивное кеширование страниц снижает нагрузку и повышает шансы пережить слабую атаку. А главное — заранее записанный план: куда звонить, как быстро подключается платная фильтрация трафика, кто принимает решение. Покупать дорогую защиту «на всякий случай» небольшому сайту обычно не нужно; терять сутки в сезон на поиск решения с нуля — самый дорогой вариант из возможных.

Фишинговые клоны и подмена бренда

Эта угроза бьет по бизнесу, не касаясь его сервера. Атакующий копирует сайт, вешает копию на похожий домен (лишняя буква, другая зона) и приводит туда трафик — рекламой по вашему бренду или рассылкой по чужим базам. Клиенты оставляют заявки и оплачивают заказы, думая, что имеют дело с вами. Претензии потом тоже приходят вам.

Масштаб индустрии: только за май 2026 года Центр мониторинга и управления сетью связи общего пользования заблокировал 7191 фишинговый ресурс и еще 457 сайтов с вредоносным ПО. Это заблокированные за 1 месяц; сколько работает прямо сейчас, не знает никто.

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

Защита:

• Мониторинг доменов. Периодическая проверка, не зарегистрирован ли клон с опечаткой; очевидные варианты написания бренда дешевле зарегистрировать самим.
• Почтовые подписи SPF, DKIM и DMARC. Они мешают рассылать письма «от вашего имени» и заодно улучшают доставляемость собственных рассылок.
• Жалобы на клоны. Регистратору домена-клона, хостеру, в поисковые системы. Блокировки по жалобам работают, хоть и не мгновенно.
• Правило для команды. В панели хостинга, регистратора и Вебмастера входим только по своим закладкам, никогда по ссылкам из писем.

Атаки через чужой код на вашем сайте

Средний сайт выполняет заметное количество чужого кода: счетчики аналитики, виджеты чатов и карт, шрифты с внешних CDN, JS-библиотеки. Каждый такой скрипт работает в браузере посетителя с теми же правами, что и ваш собственный код. Если поставщика виджета взломали, зловред раздается всем сайтам, где виджет установлен, — включая ваш, хотя у вас не сломано ничего.

Проблема выросла настолько, что в OWASP Top 10 редакции 2025 года появилась отдельная категория A03 «Software Supply Chain Failures» — сбои цепочки поставок ПО. Туда же относятся зараженные пакеты в репозиториях и скомпрометированные обновления: атакуют не сайт, а то, из чего сайт собран.

Защита: держать список сторонних скриптов коротким и осознанным; все, что можно, размещать локально на своем сервере; для внешних скриптов использовать атрибут целостности SRI, а политикой Content-Security-Policy ограничивать, откуда странице вообще разрешено загружать код. И простая привычка: перед установкой очередного виджета спросить, окупает ли его польза еще одну точку чужого доступа к вашим посетителям.

Утечки данных: самая дорогая из угроз

По данным Роскомнадзора, за 2025 год зафиксировано 118 случаев утечек баз персональных данных, в сеть попали более 52 млн записей. Для компании утечка — единственная угроза из списка, у которой есть прямой законодательный ценник: с мая 2025 года за повторную утечку действуют оборотные штрафы — от 1 до 3% годовой выручки, но не менее 20 млн и не более 500 млн руб.

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

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

С чего начинать защиту: порядок действий

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

1. Обновления. CMS, модули, PHP. Проверить текущие версии, накатить критические обновления безопасности, назначить ответственного за регулярность.
2. Доступы. Сменить пароли на уникальные, включить двухфакторную аутентификацию, провести ревизию учеток и закрыть все, чьих владельцев вы не можете назвать.
3. Резервные копии. Автоматические, на отдельной площадке, с проверкой восстановления. Бэкап, из которого ни разу не восстанавливались, — это гипотеза.
4. HTTPS и заголовки безопасности. Валидный сертификат с автопродлением, редирект на https, базовые заголовки вроде X-Content-Type-Options и Content-Security-Policy.
5. Чистка. Удалить неиспользуемые модули, тестовые скрипты, дампы и архивы из публичных папок.
6. Штатные средства CMS. В Битриксе — модуль «Проактивная защита»: веб-антивирус, контроль целостности, журнал вторжений. Он уже куплен вместе с лицензией, его надо только включить и настроить.
7. Мониторинг. Подтвержденные права в Яндекс Вебмастере и Google Search Console, чтобы о проблемах безопасности вы узнавали из панели раньше клиентов.
8. План реакции. Один документ: контакты хостера и разработчиков, где лежат бэкапы, порядок действий при взломе, DDoS и утечке.

Это уровень гигиены. Он не остановит целевую атаку серьезной группировки, но целевые атаки на небольшие сайты — экзотика. Гигиена закрывает именно то, что приходит каждый день: автоматический перебор, сканеры уязвимостей, массовые заражения. Для более глубокой проверки есть чек-лист технического аудита из 30 проверок, а быстрый внешний срез по сертификату, заголовкам и настройкам можно получить за пару минут через наш сервис проверки сайтов — он прогоняет 39 автоматических тестов.

Чего бояться на самом деле

Медийный образ угроз и реальная статистика инцидентов расходятся. В новостях — DDoS на 2 Тбит/с и хакерские группировки. В разборах взломанных небольших сайтов — пароль «Company2019» у трех сотрудников сразу, Битрикс без обновлений с позапрошлого года и FTP-доступ подрядчика, уволенного до пандемии.

Я считаю, что страх перед «профессиональным хакером» для малого и среднего бизнеса переоценен. До целевой атаки большинство сайтов просто не доживает: их раньше находит бот по открытой уязвимости или забирает словарный перебор. Обидная правда в том, что почти каждый разобранный нами в Design Lab инцидент был предотвратим мерами из предыдущего раздела, причем недорогими.

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

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