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

Что это такое
Cross-Site Scripting (XSS) — это уязвимость, которая позволяет злоумышленнику внедрить в веб-страницу вредоносный скрипт. Чаще всего это JavaScript, который браузер выполнит, думая, что это часть содержимого сайта. Есть три основных типа XSS:
- Stored (сохранённый) — скрипт сохраняется на сервере (например, в базе или комментариях) и показывается всем друзьям и гостям.
- Reflected (отражённый) — вредоносный код приходит в URL или форме и тут же выводится на странице без проверки.
- DOM-based — когда скрипт внедряется за счёт уязвимой логики в коде на клиенте.

Где применяется
Почти везде, где есть ввод данных пользователем:
- формы ввода комментариев или отзывов
- поля поиска, параметры в URL
- любые посты и блоги с пользовательским контентом
- админпанели, где можно редактировать тексты
Даже если страница только читает данные без записи, стоит проверить, как обрабатываются входящие параметры.

Практические примеры
1. Представим форму с комментарием, куда нельзя вставлять тег <script>, но не фильтруете кавычки. Злоумышленник может вставить что-то вроде:
`"><script>alert('XSS')</script>`
Если вывод не экранируется, браузер это выполнит.
2. В URL есть параметр `?name=`, и вы просто вставляете его в страницу:
`Привет, <span id="user">[name из URL]</span>`
Без особой обработки здесь тоже можно подставить скрипт.
3. При обработке данных через JavaScript на клиенте — если вы напрямую вставляете данные в innerHTML, а не используете textContent или шаблонизаторы с защитой, это открывает доступ к DOM-based XSS.

Типичные ошибки
- Нет фильтрации входящих данных.
- Использование innerHTML для вывода пользовательского ввода.
- Отсутствие или неправильное экранирование специальных символов (<, >, ", ').
- Хранение вредоносного кода в базе и показ его без обработки.
- Перепутанные контексты — например, вставлять данные, предназначенные для текста, в атрибут HTML без экранирования.
- Ожидание, что Content Security Policy (CSP) решит все проблемы — это дополнительный барьер, но не панацея.

Полезные инструменты
- OWASP ZAP или Burp Suite для сканирования страниц на XSS.
- Библиотеки для защиты — например, DOMPurify для очистки HTML перед выводом.
- Фреймворки, которые автоматически экранируют вывод (React, Vue, Angular).
- Консоль браузера и инструменты разработчика для проверки, где и как выводятся данные.
- Проверка CSP — она позволяет ограничить выполнение скриптов, снизив ущерб от потенциальных XSS.

FAQ
- Можно ли полностью исключить XSS?
В идеале — да, если правильно фильтровать и экранировать все вводимые данные и не вставлять их напрямую в HTML без обработки.
- Почему не хватает только фильтрации?
Потому что данные могут попадать в разные части страницы (HTML, атрибуты, JS, URL), и для каждого контекста нужны свои меры защиты.
- Стоит ли использовать CSP?
Да, это дополнительный слой безопасности, особенно для блокировки внешних скриптов и inline-скриптов, но без правильной обработки данных это не решит проблему.

Вывод
Защита от XSS — это комплекс мер: валидировать и экранировать ввод, не использовать innerHTML с пользовательскими данными, применять проверенные библиотеки и инструменты, а также настроить CSP. Важно понимать, где и как пользовательские данные попадают на страницу и как браузер их интерпретирует. Создайте чёткий чек-лист для разработчиков, чтобы не пропускать эти шаги при любом изменении сайта.

А как вы обычно проверяете свои проекты на XSS? Есть ли у вас любимые инструменты или лайфхаки?