Content Security Policy (CSP) — це механізм браузера, який дозволяє розробникам додатків визначати, які ресурси можуть завантажуватись і виконуватись у контексті сторінки. Завдяки CSP можна значно знизити ризик атак типу cross‑site scripting (XSS) та інших небажаних поведінок, таких як ін’єкція неавторизованого коду JavaScript. У середовищах, заснованих на Next.js і React, де компоненти динамічно рендеряться, впровадження CSP вимагає продуманої конфігурації, щоб не порушити функціональність додатку.
Модель загрози – чому CSP потрібен у додатках React/Next.js
Сучасні фронтенд‑додатки часто завантажують скрипти з багатьох джерел: CDN, власного сервера, а також динамічно генеровані inline‑скрипти (наприклад, вбудовані в шаблони HTML). Зловмисники можуть використати уразливості у санітизації вхідних даних, щоб ін’єктувати власний код JavaScript, що призводить до викрадення токенів, сесій або виконання неавторизованих операцій. CSP працює як захисний шар, блокуючи неавторизовані джерела і примушуючи використовувати безпечні методи завантаження ресурсів.
Як працює CSP – базові директиви та їх значення
Політика CSP визначається в заголовку HTTP Content‑Security‑Policy або в тегу <meta>. Найважливіші директиви:
default-src– типове джерело для всіх типів ресурсів, якщо інша директива не вказана.script-src– контролює, звідки можуть походити скрипти JavaScript.style-src– визначає дозволені джерела CSS‑стилів.img-src– регулює походження зображень.connect-src– визначає, з яких адрес додаток може встановлювати з’єднання (наприклад, API, WebSocket).
На практиці найважливіший script-src, оскільки саме він безпосередньо захищає від XSS. Рекомендується використовувати хеші ('sha256-…') або nonce ('nonce‑…') для inline‑скриптів, замість покладання на 'unsafe-inline', який вимикає захист.
Приклад політики CSP для Next.js
Нижче наведено мінімальну, але ефективну політику CSP, яку можна додати у файл next.config.js за допомогою middleware або у функції getServerSideProps:
module.exports = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'Content-Security-Policy',
value: "default-src 'self'; script-src 'self' 'sha256-abc123' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.example.com; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'"
}
]
}
];
}
};
Ця політика дозволяє лише скрипти, що походять з власного хоста та одного довіреного CDN, а inline‑скрипти мають бути захищені хешем. Для стилів дозволено 'unsafe-inline' лише у виняткових випадках, що є компромісом при використанні бібліотек CSS‑in‑JS.
Фрагменти коду: вразливий vs. виправлений
Розглянемо простий компонент React, який вставляє вміст, отриманий з API, без санітизації:
function UnsafeComponent({html}) {
return ;
}
Такий підхід вразливий до XSS, оскільки будь‑який HTML‑код може бути виконаний. Виправлена версія використовує бібліотеку для санітизації і одночасно обмежує CSP довіреними джерелами:
import DOMPurify from 'dompurify';
function SafeComponent({html}) {
const cleanHtml = DOMPurify.sanitize(html);
return ;
}
Поєднання санітизації на боці додатку з суворою політикою CSP значно підвищує рівень безпеки.
«CSP не є магічним щитом – це елемент захисного шару, який має працювати разом із безпечним кодом.»
Чек‑лист впровадження CSP у Next.js і React
- Визначте всі джерела скриптів, стилів, зображень і з’єднань, що використовуються у проєкті.
- Встановіть, які inline‑скрипти є необхідними; замініть їх на хеші або nonce‑и.
- Налаштуйте заголовок CSP у
next.config.jsабо на проміжному сервері (NGINX, Vercel). - Увімкніть звітування CSP (директива
report-uriабоreport-to) і моніторьте логи. - Тестуйте політику у режимі звітування (
Content-Security-Policy-Report-Only) перед включенням у блокуючому режимі. - Використовуйте інструменти розробника браузера для аналізу порушень CSP і коригуйте політику.
Типові помилки та компроміси при впровадженні CSP
Найпоширеніші пастки:
- Використання
'unsafe-inline'або'unsafe-eval'– повністю вимикає захист від XSS. - Застарілі хеші – після зміни коду хеш має бути оновлений, інакше політика блокує легітимний код.
- Занадто суворий
default-srcбез належного підбору під‑директив – може призвести до того, що додаток перестане завантажувати необхідні ресурси, наприклад шрифти або зображення. - Відсутність звітування – без увімкненого звітування важко виявити, які ресурси блокуються і чому.
Рішенням є ітеративний підхід: спочатку запустіть політику в режимі Report‑Only, зберіть дані, а потім переключіться в режим блокування після усунення всіх хибних тривог.
Налагодження порушень CSP у браузері та звітування
У консолі розробника Chrome і Firefox з’являються повідомлення типу Refused to load the script … because it violates the following Content Security Policy directive: "script-src …". Клік по повідомленню відкриває перегляд, який ресурс був заблокований. Додатково, якщо налаштовано report-uri, сервер отримає JSON з інформацією про порушення, що дозволяє автоматичний аналіз і оновлення політики.
Підтримка та оновлення політики CSP
Політика CSP не є одноразовим налаштуванням – вона потребує регулярного перегляду. Кожна нова бібліотека, CDN або функція (наприклад WebSocket) може вимагати додавання відповідних джерел до директив. Хорошою практикою є інтеграція e2e‑тестів, які перевіряють, чи працює додаток при увімкненому CSP, а також моніторинг звітів у системі SIEM або спеціальному endpoint‑і.
Підсумовуючи, впровадження Content Security Policy у проектах Next.js і React – це процес, який поєднує точну інвентаризацію ресурсів, правильну конфігурацію заголовків та постійний моніторинг. Завдяки цьому інженерна команда може значно знизити ризик XSS, зберігаючи повну функціональність додатку. Якщо вам потрібна допомога з аудитом безпеки, налаштуванням CSP або інтеграцією звітування, зв’яжіться з нами в Coderia.it – разом ми створимо надійний захисний щит для вашого коду.



