Что такое Content Security Policy (CSP) и как он связан с безопасностью?

Что проверяют

Понимаете ли вы, что CSP это второй рубеж против XSS, а не замена экранированию, и умеете ли включить его так, чтобы он реально защищал. Следом спрашивают, чем плох 'unsafe-inline' и как тогда быть с инлайн-скриптами.

Как отвечать

CSP это политика, которую сервер отдаёт заголовком Content-Security-Policy. По ней браузер решает, откуда странице можно грузить и выполнять скрипты, стили, картинки, запросы и фреймы. Если злоумышленник всё же внедрил <script>, при правильной политике браузер его не выполнит.

Ключевые директивы:

• default-src: запасное правило для всего, что не описано отдельно;
• script-src: главная директива против XSS;
• connect-src: куда можно ходить через fetch и WebSocket, мешает вывести украденные данные;
• frame-ancestors: кто может встроить вашу страницу в iframe. Защищает от кликджекинга и заменяет X-Frame-Options;
• object-src 'none' и base-uri 'none': закрывают старые обходы через плагины и подмену <base>.

Современный подход называется strict CSP: вместо списка доменов разрешать скрипты по одноразовому nonce или по хэшу содержимого, плюс 'strict-dynamic', чтобы доверенный скрипт мог подгружать свои зависимости. Списки доменов обходятся, если на разрешённом CDN лежит библиотека, через которую можно исполнить код.

Внедряют политику постепенно: сначала заголовок Content-Security-Policy-Report-Only, нарушения собирают через report-to, чинят и только потом включают блокировку.

Где спотыкаются

Добавляют 'unsafe-inline' и 'unsafe-eval', чтобы всё заработало. Заголовок есть, а защиты от XSS почти нет.

Задают политику через <meta> и ждут, что заработают frame-ancestors и отчёты. В мета-теге они не поддерживаются, нужен HTTP-заголовок.

Делают nonce статичным. Он должен быть случайным для каждого ответа, а значит плохо сочетается с кэшированной статической страницей: там вместо nonce используют хэши скриптов.