Безопасность фронтенда: настройка CSP, SRI и защита от XSS в 2026 году

Представьте ситуацию: вы запустили новый сайт, пользователи довольны, конверсия растёт. Но через неделю приходит письмо от клиента - кто-то вставил рекламный скрипт прямо в их личный кабинет. Классический XSS. Проблема не в том, что хакер гениален, а в том, что браузеры по умолчанию доверяют всему коду, который попадает на страницу. В 2026 году, когда SPA-приложения стали нормой, а CDN делят трафик между десятками серверов, старые методы защиты перестали работать. Нужна многослойная оборона.

Сегодня мы разберём три ключевых инструмента: Content Security Policy (CSP) is a mechanism that allows developers to control which resources can be loaded on a web page., Subresource Integrity (SRI) is a security feature that verifies the integrity of third-party scripts using cryptographic hashes. и практические приёмы борьбы с кросс-сайтовым скриптингом. Это не теория для учебника, а конкретные шаги, которые спасут ваш продакшн от инцидентов.

Почему стандартных методов уже мало

Многие разработчики полагаются на экранирование HTML-сущностей и считают, что этого достаточно. Но реальность сложнее. Современные приложения загружают зависимости из десятков источников: шрифты с Google Fonts, библиотеки с jsDelivr, аналитика с Cloudflare. Каждый такой запрос - потенциальная точка входа. Если CDN будет взломан или DNS-спуфинг произойдёт, пользователь получит поддельный код, и браузер выполнит его без вопросов.

Здесь на помощь приходят механизмы, встроенные в современные браузеры. Они работают на уровне ядра браузера, а не JavaScript, поэтому их сложнее обойти. Давайте посмотрим, как они устроены и почему их комбинация даёт максимальную защиту.

Content Security Policy: правила игры для браузера

CSP работает как строгий охранник на входе. Вы задаёте список разрешённых источников для скриптов, стилей, изображений и шрифтов. Браузер проверяет каждый запрос против этого списка. Если источник не совпадает - ресурс блокируется.

Настройка начинается с заголовка HTTP Content-Security-Policy или мета-тега в HTML. Начните с режима report-only, чтобы не сломать работу сайта мгновенно. Посмотрите, какие ресурсы реально используются, и только потом переходите к жёсткому режиму.

• script-src: Укажите точные домены для JS. Избегайте * (wildcard) там, где можно обойтись без него.
• style-src: Разрешите только необходимые стили. Inline-стили лучше выносить в файлы.
• img-src: Ограничьте источники картинок, если они не критичны для безопасности.
• connect-src: Контролируйте AJAX-запросы и WebSocket соединения.

Особое внимание уделяйте inline-скриптам. Если вам нужно оставить их (например, для конфигурации), используйте nonce или hash. Nonce генерируется сервером при каждом ответе, что делает атаку «подмены» практически невозможной.

Subresource Integrity: проверка подписи кода

CSP решает вопрос «откуда грузится код», но не отвечает на вопрос «не изменился ли он по дороге». Для этого существует SRI. Принцип простой: вы указываете криптографический хэш файла (SHA-384 или SHA-512) прямо в теге <script> или <link>. Браузер скачивает файл, считает хэш и сравнивает его с указанным. Если не совпадает - файл игнорируется.

Это критически важно для библиотек, загружаемых с CDN. Представьте, что вы используете React с unpkg.com. Если злоумышленник перехватит соединение или взломает CDN, он сможет заменить bundle на вредоносный. С SRI это станет невозможно без изменения хэша в вашем коде.

Практическая борьба с XSS: не только экранирование

Кросс-сайтовый скриптинг делится на два типа: отражённый (reflected) и сохраняемый (stored). Отражённый возникает, когда пользовательская ввод передаётся обратно в URL или параметрах. Сохраняемый - когда данные пишутся в базу данных и выводятся позже. Оба типа опасны, но защищаться нужно комплексно.

Первое правило: никогда не доверяй пользователю. Даже если вы используете React или Vue, которые автоматически экранируют HTML, есть лазейки. Например, атрибут dangerouslySetInnerHTML в React или v-html в Vue отключают автоэкранирование. Используйте их только после тщательной очистки данных через библиотеки вроде DOMPurify.

Второе правило: ограничивайте контекст выполнения. Если скрипт должен выполняться только на главной странице, не позволяйте ему работать на страницах авторизации. Третье: используйте HTTPS везде. Без шифрования протокола любая попытка защиты может быть обойдена через MITM-атаку.

Типичные ошибки и как их избежать

Даже опытные команды допускают просчёты. Вот самые частые:

1. Слишком широкие CSP. Если вы пишете script-src 'self' https://*.cdn.com, вы открываете дверь для любого скрипта с этого CDN. Лучше указать конкретные пути или использовать nonce.
2. Забытый SRI для CSS. Многие добавляют хэши только для JS, забывая о стилях. Подмена CSS может скрыть важные элементы интерфейса или изменить поведение форм.
3. Отсутствие мониторинга. CSP генерирует отчёты об ошибках. Если вы не собираете их в централизованную систему, вы не узнаете о проблемах, пока их не заметит пользователь.
4. Жёсткая привязка к версии. Если вы обновляете библиотеку на CDN, хэш меняется. Забудьте обновить тег в HTML - и сайт сломается. Автоматизируйте этот процесс в CI/CD пайплайне.

Также стоит помнить про frame-ancestors в CSP. Он защищает от Clickjacking, ограничивая, какие сайты могут встроить вашу страницу в iframe. Это часто упускают из виду, хотя атака через клик по прозрачному overlay всё ещё актуальна.

Чек-лист перед релизом

Перед тем как отправлять проект в прод, пройдите по этому списку. Он займёт 15 минут, но сэкономит часы дебага.

• Проверьте наличие заголовка Content-Security-Policy в ответе сервера.
• Убедитесь, что все внешние скрипты имеют атрибут integrity с корректным хэшем.
• Тестируйте форму регистрации и комментариев на инъекцию <script> тегов.
• Проверьте, что inline-скрипты используют nonce или hash.
• Убедитесь, что HTTPS включён для всех поддоменов.
• Настройте сборку CSP-отчётов на отдельный endpoint.

Безопасность фронтенда - это не разовое действие, а процесс. Технологии меняются, появляются новые уязвимости. Но базовый набор инструментов остаётся прежним: контролируйте источники, проверяйте целостность и не доверяйте данным. Эти три принципа защитят вас от 90% типовых атак.