XSS — это когда текст, введённый в форму, выполняется как скрипт на чужом экране. Вот как он работает и как его надёжно предотвратить (без шагов атаки).
Три типа
XSS делится по тому, «как вредоносная строка доходит до выполнения».
| Тип | Как подставляется |
|---|---|
| Хранимый | Сохраняется в посте/профиле и выполняется у каждого, кто его просматривает (самый опасный) |
| Отражённый | Параметр URL отражается прямо обратно в страницу; выполняется у того, кто кликает по ссылке |
| DOM-based | Без обращения к серверу — клиентский JS небезопасно обрабатывает ввод |
Почему это опасно (как работает)
Браузер выполняет любой <script> на странице как «легитимный код». Если строка атакующего попадает как HTML в страницу, браузер не может отличить её от настоящего кода.
Ущерб — «всё, что может эта страница». Если RCE — самая серьёзная уязвимость на стороне сервера, то XSS — самая серьёзная на стороне клиента (пользователя).
Защита: экранируйте на выводе
XSS предотвращается на выводе, а не на вводе. В тот миг, когда вы выводите значение, преобразуйте его так, чтобы оно не могло быть интерпретировано как HTML.
Экранируйте на выводе (самое важное)
При выводе значений от пользователя преобразуйте < > & " ' в HTML-сущности — используя правильный метод для контекста (тело HTML, атрибут, JS, URL).
Не отключайте авто-экранирование вашего фреймворка
React/Vue/шаблоны авто-экранируют по умолчанию. Просто избегайте внедрения сырого HTML (dangerouslySetInnerHTML, v-html), и вы предотвратите большинство XSS.
Эшелонированная защита с CSP
Content-Security-Policy позволяет браузеру блокировать скрипты, которые вы не разрешали, ограничивая ущерб, даже если что-то проскользнёт.
Защитите cookie
Помечайте сессионные cookie HttpOnly, чтобы JS не мог их прочитать. Даже если XSS проскользнёт, ущерб будет меньше.
Мнение этого сайта: лучшая защита — не отключать механизмы безопасности самому
Современные фреймворки безопасны по умолчанию. Большинство XSS появляется в тот момент, когда разработчик намеренно отключает авто-экранирование, чтобы «внедрить сырой HTML». Если HTML действительно нужно разрешить, пропускайте его через проверенный санитайзер, а не через собственную обработку строк. «Отключение безопасности ради удобства» — самый большой риск.
Чем XSS отличается от атак, с которыми его путают
XSS часто путают с CSRF из-за похожего названия и с SQL-инъекцией, где ввод тоже воспринимается как команда. Разница — в том, что выполняется и где.
| Атака | Что и где происходит | Основная защита |
|---|---|---|
| XSS | Скрипт атакующего выполняется в браузере пользователя как часть настоящей страницы | Экранирование на выводе, CSP |
| CSRF | Сессия вошедшего пользователя используется для отправки запроса, которого он не хотел. Выполнять скрипт не нужно | CSRF-токены, cookie SameSite |
| SQL-инъекция | Ввод интерпретируется на сервере как часть SQL-запроса | Плейсхолдеры |
| Кликджекинг | Настоящая страница невидимо накладывается, и пользователь кликает по ней, не зная об этом | CSP frame-ancestors |
Учтите, что XSS обходит и защиту от CSRF. Как только скрипт выполняется внутри страницы, он может прочитать и CSRF-токен на этой странице (руководство OWASP по CSRF предупреждает о том же).
Реальный пример: XSS на экране, который открывают сотрудники
В 2026 году Instructure — компания, разрабатывающая систему управления обучением Canvas, — сообщила, что вторжение началось с XSS. По словам компании, атакующий с бесплатной учётной записи отправил обращение в поддержку с вредоносным кодом, а когда сотрудник поддержки открыл его, уязвимость XSS была использована для получения повышенных привилегий внутри Canvas (→ утечка данных Canvas (Instructure), на английском).
Урок в том, что XSS — проблема не только публичных страниц. Экраны поддержки, обратной связи и администрирования, где вашим сотрудникам показывается текст, присланный извне, рискованнее, потому что у учётных записей, которые их открывают, больше полномочий.
XSS по-прежнему среди самых распространённых слабостей. В «CWE Top 25» MITRE (25 самых опасных слабостей ПО), опубликованном в декабре 2025 года, XSS (CWE-79) занял первое место. В сентябре 2024 года американские CISA и ФБР также выпустили предупреждение с призывом к производителям ПО устранить XSS из своих продуктов.
Как проверить свой сайт
Пробовать строки атаки не нужно. Начните с этих четырёх проверок.
Найдите места, куда вставляется сырой HTML
Поищите в коде dangerouslySetInnerHTML, v-html, innerHTML и document.write и проверьте, может ли туда попасть значение от пользователя. Если может — выводите его как текст или пропускайте через проверенный санитайзер.
Проверьте, отправляется ли CSP
С помощью проверки заголовков безопасности посмотрите, есть ли Content-Security-Policy и что она разрешает. Разрешение 'unsafe-inline' сильно ослабляет её против XSS. Чтобы написать новую, составьте черновик в конструкторе CSP и сначала запустите её в режиме Report-Only (только сообщает о нарушениях).
Проверьте флаги сессионной cookie
В инструментах разработчика браузера (Application → Cookies) убедитесь, что у сессионной cookie есть HttpOnly и Secure. Флаги cookie проверяет и аудит сайта.
Не забудьте экраны администрирования и поддержки
Проверьте, что внутренние экраны, показывающие текст извне (тексты обращений, имена файлов, отображаемые имена), экранируются по тем же правилам, что и публичные страницы.
Источники (первичные)
- OWASP, «Cross Site Scripting Prevention Cheat Sheet» — cheatsheetseries.owasp.org (экранирование под контекст вывода, безопасные настройки фреймворков по умолчанию)
- MITRE, «2025 CWE Top 25 Most Dangerous Software Weaknesses» (декабрь 2025 г.) — cwe.mitre.org (CWE-79 на первом месте)
- CISA и ФБР, «Secure by Design Alert: Eliminating Cross-Site Scripting Vulnerabilities» (17 сентября 2024 г.) — cisa.gov
- OWASP, «Cross-Site Request Forgery Prevention Cheat Sheet» — cheatsheetseries.owasp.org (XSS может обойти защиту от CSRF)
- IPA, «How to Secure Your Web Site» — ipa.go.jp (на японском)
Читать дальше
- Глоссарий: Что такое CSRF · Что такое RCE · Что такое JWT (токен, который часто крадут через XSS)
- Основы: Основы безопасности
- Эшелонированная защита: заголовки безопасности — не список, который нужно наращивать (CSP сужает возможности XSS)