Політика безпеки вмісту в Next.js – практичний посібник крок за кроком

Дізнайтеся, як безпечно впровадити CSP у проектах Next.js і React, захищаючи додатки від XSS без втрати функціональності.

Content Security Policy w Next.js – praktyczny przewodnik krok po kroku

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 – разом ми створимо надійний захисний щит для вашого коду.

Почнімо

Маєте проєкт на думці?

Опишіть його кількома реченнями. Відповім протягом 24 годин із безкоштовною оцінкою та пропозицією стеку.