Content Security Policy

Content Security Policy (CSP) — это механизм безопасности веб-приложений, который позволяет контролировать, какие ресурсы могут загружаться и выполняться на странице. CSP предотвращает атаки типа Cross-Site Scripting (XSS), инъекции данных и другие угрозы, связанные с выполнением непроверенного кода.

CSP работает через заголовок HTTP Content-Security-Policy или мета-тег <meta http-equiv="Content-Security-Policy">, где задаются правила для различных типов ресурсов: скриптов, стилей, изображений, шрифтов и т.д.

Пример базового заголовка CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline';

Здесь:

  • default-src 'self' — по умолчанию разрешается загружать ресурсы только с того же домена.
  • script-src — разрешает скрипты с собственного домена и с CDN.
  • style-src — разрешает стили с собственного домена и встроенные стили ('unsafe-inline').

Основные директивы CSP

1. default-src Устанавливает источник по умолчанию для всех типов ресурсов, если для конкретного типа не задано отдельное правило.

default-src 'self';

2. script-src Определяет разрешённые источники для JavaScript. CSP запрещает выполнение скриптов с недоверенных доменов.

script-src 'self' https://cdnjs.cloudflare.com;

Дополнительно можно использовать 'nonce-<value>' или 'hash-<value>' для разрешения конкретных встроенных скриптов.

3. style-src Контролирует загрузку CSS и inline-стилей. Inline-стили по умолчанию блокируются, если не указан 'unsafe-inline' или nonce.

style-src 'self' 'unsafe-inline';

4. img-src Определяет, откуда могут загружаться изображения.

img-src 'self' https://images.example.com;

5. connect-src Контролирует, куда могут уходить запросы AJAX, WebSocket, EventSource.

connect-src 'self' https://api.example.com;

6. font-src Определяет разрешённые источники шрифтов.

font-src 'self' https://fonts.googleapis.com;

7. frame-src / child-src Определяет допустимые источники для <iframe> и других вложенных окон.

frame-src https://player.vimeo.com;

Методы внедрения CSP

  1. Через HTTP-заголовок Наиболее надёжный способ, используется на сервере. Пример для Nginx:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self';";
  1. Через HTML-мета-тег Менее безопасно, так как злоумышленник может изменить мета-тег при XSS-уязвимости:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self';">

Nonce и Hash для inline-скриптов

Для разрешения выполнения inline-скриптов без открытия уязвимостей используют nonce или hash.

Пример использования nonce:

<script nonce="random123">console.log('Разрешённый скрипт');</script>

Заголовок CSP:

Content-Security-Policy: script-src 'self' 'nonce-random123';

Пример использования hash:

<script>
console.log('Разрешённый скрипт с hash');
</script>

Заголовок CSP:

Content-Security-Policy: script-src 'self' 'sha256-AbCdEf123456...';

Полезные рекомендации при настройке CSP

  • Всегда начинать с default-src 'self' и постепенно открывать источники.
  • Избегать 'unsafe-inline' и 'unsafe-eval', если это возможно.
  • Использовать nonce для inline-скриптов, особенно в динамических приложениях.
  • Проверять отчёты CSP через директиву report-uri или report-to:
Content-Security-Policy: default-src 'self'; report-uri /csp-violation-report-endpoint;
  • Тестировать CSP в режиме Content-Security-Policy-Report-Only перед полным внедрением.

Отладка CSP

Для анализа нарушений CSP можно использовать:

  • Консоль браузера (Chrome, Firefox) — показываются заблокированные ресурсы.
  • Инструменты DevTools: вкладка Security или Network.
  • Серверные отчёты через report-uri.

Content Security Policy — мощный инструмент для защиты веб-приложений. Его грамотная настройка минимизирует риск XSS и других уязвимостей, но требует внимательного подхода к использованию inline-ресурсов и внешних библиотек.

Оглавление