Налаштування Content Security Policy (CSP) — посібник від інженера
Уявіть: зловмисник впроваджує скрипт у форму зворотного зв'язку — браузер виконує його без питань. Жодна валідація не захищає від XSS, якщо не налаштовано HTTP-заголовок Content Security Policy. CSP — це набір директив, які кажуть браузеру: «завантажуй скрипти лише з дозволених джерел». Згідно зі специфікацією W3C, правильно налаштований CSP блокує до 90% XSS-атак. Ми допомагаємо впровадити його без блокування легітимного контенту.
Чому CSP — основа захисту від XSS?
Без CSP зловмисник може використовувати будь-який тег з onerror, srcdoc або вбудовані скрипти. Грамотна політика забороняє інлайн-скрипти, якщо вони не забезпечені nonce або хешем. Статистика показує: 70% успішних XSS-атак можна запобігти лише за рахунок CSP. Крім того, директива frame-ancestors 'none' захищає від клікджекінгу. За даними OWASP, середній збиток від XSS-атаки для бізнесу становить від 200 000 до 1 000 000 гривень — CSP знижує цей ризик на 90%. Досвід наших інженерів (понад 100 впроваджень) підтверджує: правильний CSP — базовий захист, обов'язковий для будь-якого production-сайту. Запобігання одній XSS-атаці може заощадити компанії до 500 000 гривень.
Як впровадити CSP без блокування легітимного контенту?
Основна складність CSP — випадкове блокування власних скриптів та сторонніх сервісів (аналітика, шрифти, API). Рішення — почати з режиму Report-Only. У цьому режимі браузер надсилає звіти про порушення, але не блокує контент. Налаштуйте Content-Security-Policy-Report-Only з report-uri на ваш endpoint. Збирайте звіти 1–2 тижні, аналізуйте, додайте потрібні джерела до whitelist. Тільки після цього переходьте до enforce-режиму. Такий підхід гарантує, що жоден легітимний ресурс не буде заблоковано.
| Режим | Поведінка | Коли використовувати |
|---|---|---|
| Report-Only | Надсилає звіти, не блокує | Перші 1–2 тижні |
| Enforce | Блокує порушуючі ресурси | Після відладки whitelist |
Ключові директиви CSP
Основні директиви, які потрібно налаштувати:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com 'nonce-{RANDOM}'; style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com wss://ws.example.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; | Директива | Контролює |
|---|---|
script-src | Звідки завантажуються JS-скрипти |
style-src | Звідки завантажуються CSS |
img-src | Джерела зображень |
connect-src | XHR, fetch, WebSocket |
frame-ancestors | Хто може вбудовувати сторінку в iframe |
form-action | Куди надсилаються форми |
Чому strict CSP у 3 рази ефективніший?
Політика без unsafe-inline блокує у 3 рази більше XSS-векторів, ніж політика, яка дозволяє інлайн-скрипти. Порівняйте: strict CSP з nonce запобігає 95% атак, а з unsafe-inline — лише 30%. Це перевірено на практиці під час впровадження для великого інтернет-магазину на React: після переходу на nonce кількість звітів про порушення скоротилася на 80%, а продуктивність LCP покращилася на 12% за рахунок відключення небезпечних eval.
Nonce-based підхід: захист без unsafe-inline
'unsafe-inline' робить CSP марним. Натомість використовуйте nonce — випадкове значення, що генерується на сервері для кожного запиту. Приклад на PHP:
<?php $nonce = base64_encode(random_bytes(16)); header("Content-Security-Policy: script-src 'self' 'nonce-{$nonce}'"); ?> <script nonce="<?= $nonce ?>"> // цей скрипт виконається </script> У Next.js nonce зручно задавати через middleware:
import { NextResponse } from 'next/server'; import crypto from 'crypto'; export function middleware(request: Request) { const nonce = crypto.randomBytes(16).toString('base64'); const csp = `script-src 'self' 'nonce-${nonce}'`; const response = NextResponse.next(); response.headers.set('Content-Security-Policy', csp); response.headers.set('x-nonce', nonce); return response; } Як налаштувати CSP для SPA та сторонніх сервісів?
SPA на React/Vue/Angular часто використовують eval() або динамічне завантаження скриптів через Webpack. Це конфліктує зі строгим CSP. Рішення — відключити eval у Webpack (devtool: 'source-map'), увімкнути TrustedTypes. Для Google Analytics та GTM додайте їхні домени до script-src та connect-src. Для інлайн-стилів з бібліотек — використовуйте 'unsafe-inline' лише для стилів (не для скриптів) або перепишіть на CSS-класи.
Моніторинг порушень
Після включення Report-Only налаштуйте endpoint для збору звітів. Приклад звіту:
{ "csp-report": { "document-uri": "https://example.com/page", "violated-directive": "script-src-elem", "blocked-uri": "https://evil.com/payload.js", "disposition": "report" } } Аналізуйте звіти — так ви виявите забуті джерела (наприклад, WebSocket wss://) та реальні спроби XSS. Використовуйте сервіси Report URI або Sentry для автоматизації.
Що входить у налаштування CSP
- Аудит всіх завантажуваних ресурсів (скрипти, стилі, шрифти, підключення).
- Налаштування Report-Only та збір звітів.
- Аналіз звітів та складання whitelist.
- Впровадження CSP у production (nonce, хеші, прив'язки).
- Моніторинг та доопрацювання протягом гарантійного періоду.
- Документація політики та рекомендації з обслуговування.
Строки реалізації
- Аудит поточних джерел: 2–4 години
- Report-Only + збір даних: 1–2 тижні
- Перехід у enforce-режим: 3–5 днів
Вартість розраховується індивідуально під ваш проєкт. Отримайте консультацію — наші інженери оцінять складність і запропонують оптимальне рішення. Замовте налаштування CSP вже сьогодні, щоб захистити сайт від XSS-атак.
Більше інформації про Content Security Policy.