Генератор Content Security Policy

Як створити політику

1. Виберіть відправну точку в розділі Почати з шаблону: Суворий (nonce + strict-dynamic), Максимально закритий статичний сайт, Типовий вебсайт або Типовий + Google Analytics / Ads. Редактор відкривається із шаблоном типового вебсайту.
2. Налаштуйте Директиви. У кожному полі джерела вказують через пробіл; порожнє поле означає, що директиву буде пропущено.
3. За допомогою Швидке додавання додайте ключове слово до вибраної Директива: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data: тощо. Кнопка Додати nonce вставляє випадковий 128-бітний nonce.
4. Щоб дозволити конкретний вбудований скрипт без 'unsafe-inline', вставте його (або HTML навколо нього) в розділ Хеш вбудованого скрипту або стилю й натисніть Обчислити SHA-256 і додати.
5. Позначте upgrade-insecure-requests (завантажувати ресурси http:// через https://), якщо деякі старі URL досі використовують http://, і за бажанням вкажіть URL кінцевої точки для звітів (необов’язково).
6. Скопіюйте HTTP-заголовок, Заголовок Report-Only (перевірка без блокування) або HTML-тег . Огляд цієї політики оновлюється під час введення.

Щоб перевірити політику, яка у вас уже є, вставте її в розділі Оцінити наявну політику й натисніть Оцінити політику; кнопка Завантажити в редактор скопіює її в поля.

Усе працює у вашому браузері: політики, які ви вставляєте, не надсилаються на сервер.

Що робить Content Security Policy

CSP повідомляє браузеру, з яких джерел сторінка може завантажувати скрипти, стилі, зображення, шрифти, фрейми та з’єднання. Її головне завдання – обмежити міжсайтовий скриптинг (XSS): навіть якщо зловмисник упровадить розмітку на вашу сторінку, добра політика не дасть вставленому скрипту виконатися. Вона також визначає, хто може вбудовувати вашу сторінку у фрейм (frame-ancestors), куди можуть надсилатися форми (form-action) і на що може вказувати <base> (base-uri).

Директиви завантаження ресурсів, як-от img-src чи font-src, переходять на default-src, якщо їх не задано. А base-uri, form-action і frame-ancestors на нього не переходять, тому огляд політики вимагає їх явно.

Nonce, хеші та strict-dynamic

Дозвіл за хостами (script-src https://cdn.example.com) здається безпечним, але його часто можна обійти: на великих доменах розміщені кінцеві точки JSONP і старі бібліотеки, які зловмисник може використати. Підхід, який радять команди з безпеки браузерів, – сувора CSP: кожен законний <script> має nonce, що його сервер генерує для кожної відповіді, або дозволений за своїм хешем, а 'strict-dynamic' дає цим довіреним скриптам змогу завантажувати потрібні їм скрипти. У такій схемі https: та 'unsafe-inline' – лише запасні варіанти для дуже старих браузерів; сучасні їх ігнорують.

Nonce працює, лише якщо він змінюється в кожній відповіді й непередбачуваний. Значення, яке вставляє кнопка Додати nonce, – лише приклад: ваш сервер чи фреймворк має генерувати власне. Хеш охоплює точні байти вбудованого коду, тож після переформатування скрипту потрібен новий хеш.

Заголовок, Report-Only і тег meta

Надсилайте політику як HTTP-заголовок відповіді, коли це можливо. Спершу розгорніть її як Content-Security-Policy-Report-Only: браузери повідомлятимуть про порушення (у консоль і на вашу кінцеву точку, якщо ви її вказали), нічого не блокуючи, тож ви зможете виправити сторінки до запровадження обмежень. Налаштування звітів додають report-uri для старіших браузерів і report-to із заголовком Reporting-Endpoints.

Версія <meta http-equiv> зручна для статичного хостингу, але браузери ігнорують у ній frame-ancestors, report-uri, report-to і sandbox, а тега meta для Report-Only не існує. Інструмент вилучає ці директиви з тега й повідомляє про це.