Как защитить приложение от XSS
Вопрос
Как бы ты выстроил защиту от XSS в большом фронтенд-приложении?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Экранирование по умолчанию: фреймворк с автоэкранированием, запрет innerHTML в линтере
Пользовательский HTML только через санитайзер (DOMPurify)
Проверка протокола у пользовательских URL в href и src
Строгая CSP с nonce и strict-dynamic, сначала в Report-Only
Trusted Types, чтобы все вставки HTML шли через одну политику
HttpOnly-куки для сессии, SRI для сторонних скриптов
Что могут спросить следом
- Как внедрить CSP в старое приложение с кучей инлайн-скриптов?
- Чем DOM-based XSS отличается от хранимой?
- Что делать со сторонними скриптами аналитики?
Разбор
Я бы строил защиту в несколько слоёв. Первый слой: не создавать уязвимости. Используем фреймворк с автоэкранированием, а опасные места вроде innerHTML и dangerouslySetInnerHTML запрещаем линтером, исключения только через ревью. Если пользователю нужно вставлять HTML, прогоняем его через DOMPurify. URL от пользователя проверяем на протокол, разрешаем только http и https. Второй слой: даже если дыра появилась, не дать ей выполниться. Для этого строгая CSP с nonce и strict-dynamic. Внедряю её сначала в режиме Report-Only, собираю отчёты, убираю инлайн-обработчики, потом включаю блокировку. Поверх включаю Trusted Types, чтобы любая вставка HTML шла через одну проверяемую политику. Третий слой: уменьшить ущерб. Сессия в HttpOnly-куке, сторонние скрипты с SRI и под контролем, секретов во фронте нет.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Термины по теме
Ещё по теме «Безопасность фронтенда»
- Защита на уровне заголовков
- XSS и как от него защищаться
- CSP
- CSRF
- Site и origin
- XSS
- Защита от кликджекинга
- Защищает ли CORS от CSRF