В 2026 году сайты собирают персональные данные почти на каждом шаге - формы заявок, авторизация, комментарии, обратная связь. Если сайт уязвим к XSS-атакам, злоумышленник может получить доступ к этим данным в обход всех организационных мер защиты. Разбираемся, что такое XSS, чем это грозит с точки зрения 152-ФЗ и как закрыть уязвимость на практике.
Коротко
- XSS (Cross-Site Scripting) - внедрение вредоносного кода на страницу сайта через незащищённые поля ввода.
- Через XSS можно перехватывать сессии пользователей, крастьcookie, формы с персональными данными и пароли.
- Ст. 19 152-ФЗ обязывает оператора применять технические меры защиты - отсутствие защиты от XSS является нарушением.
- Базовая защита - экранирование ввода/вывода и настроенный Content-Security-Policy (CSP).
- Проверить сайт на уязвимости и привести его в соответствие 152-ФЗ можно через форму аудита.
Что такое XSS простыми словами
XSS-атака - это способ внедрить в страницу сайта чужой код (чаще всего JavaScript), который выполнится в браузере другого пользователя. Уязвимость возникает там, где сайт принимает данные от пользователя - поле поиска, комментарий, форма заявки - и выводит их обратно на страницу без должной обработки.
Пример: пользователь вводит в поле имени не текст, а фрагмент кода. Если сайт не проверяет и не экранирует этот ввод, код сохраняется в базе и выполняется у каждого, кто откроет страницу с этим отзывом или заявкой.
| Тип XSS | Как работает |
|---|---|
| Хранимый (Stored) | Код сохраняется на сервере (в базе, файле) и выполняется у всех посетителей страницы |
| Отражённый (Reflected) | Код передаётся в ссылке или параметре запроса и выполняется сразу при переходе |
| DOM-based | Код выполняется на стороне браузера через уязвимый JavaScript без обращения к серверу |
Почему это риск для персональных данных
Через XSS-код, выполненный в браузере жертвы, злоумышленник может:
- перехватить cookie и получить доступ к личному кабинету пользователя;
- подменить форму на сайте и перенаправить введённые персональные данные на сторонний сервер;
- получить доступ к панели администратора, если атака направлена на сотрудника;
- незаметно собирать данные посетителей длительное время, пока уязвимость не найдена.
Важно понимать: XSS - это не абстрактная угроза для разработчиков, а прямой канал утечки персональных данных, за который отвечает оператор данных, а не хостинг или CMS сама по себе.
Как защититься: экранирование ввода, Content-Security-Policy
Экранирование ввода и вывода
Базовое правило - любые данные, введённые пользователем, при выводе на страницу должны экранироваться. Символы <, >, ", ' заменяются на безопасные HTML-сущности, чтобы браузер не воспринимал их как код. Современные фреймворки (React, Vue, Laravel, Django) делают это автоматически - но только если разработчик не отключил защиту вручную для "удобства" вывода HTML.
Content-Security-Policy (CSP)
CSP - это HTTP-заголовок, который ограничивает, откуда браузер может загружать скрипты, стили и другие ресурсы. Даже если вредоносный код попал на страницу, правильно настроенный CSP не даст ему выполниться или отправить данные на чужой сервер.
Дополнительные меры
- атрибут cookie HttpOnly - cookie сессии недоступна из JavaScript;
- атрибут SameSite - защита от подмены запросов между сайтами;
- регулярное обновление CMS, плагинов и библиотек;
- валидация данных не только на клиенте, но и на сервере.
Связь со ст. 19 152-ФЗ
Статья 19 152-ФЗ обязывает оператора персональных данных принимать необходимые правовые, организационные и технические меры для защиты данных от неправомерного доступа, уничтожения, изменения и распространения. Уязвимость к XSS - это именно техническое упущение, за которое отвечает оператор, а не просто "недоработка сайта".
Если утечка произошла из-за XSS-атаки, при проверке будет учитываться, принимались ли меры защиты вообще - было ли экранирование ввода, настроен ли CSP, проводился ли аудит безопасности. Отсутствие этих мер усиливает ответственность оператора.
Что проверить у себя на сайте
- Все формы, где пользователь вводит данные (заявки, комментарии, поиск, авторизация) - экранируется ли вывод введённых значений.
- Наличие заголовка Content-Security-Policy - настроен ли он и не работает ли сайт вовсе без него.
- Установлены ли атрибуты HttpOnly и SameSite для cookie сессии.
- Актуальность версии CMS, плагинов, тем оформления и сторонних скриптов.
- Есть ли на сайте сторонние виджеты и формы - насколько им можно доверять с точки зрения безопасности.
- Проводился ли когда-либо технический аудит сайта на уязвимости, включая XSS.
Если хотя бы один пункт вызывает сомнение, лучше не гадать, а провести проверку - оставьте заявку через форму аудита, и мы посмотрим сайт предметно.
Частые вопросы
Достаточно ли антивируса на сервере, чтобы защититься от XSS?
Нет - антивирус проверяет файлы, а XSS - это уязвимость в логике самого сайта, код внедряется через обычные поля ввода, а не через заражённый файл.
Может ли XSS привести к утечке, даже если данные хранятся у надёжного хостинг-провайдера?
Да - надёжность хостинга не влияет на уязвимости в коде самого сайта. Атака происходит на уровне приложения, а не инфраструктуры.
Нужно ли перепроверять защиту после каждого обновления сайта?
Да, желательно - новые формы, виджеты и интеграции могут снова открыть уязвимость, даже если раньше она была закрыта.
С чего начать, если непонятно, защищён ли сайт?
С независимой проверки - оставьте заявку через форму аудита, специалисты оценят сайт и подскажут конкретные шаги.