Какой текст попадает в хеш?
Работаем с алгоритмом проекта CSP Level 3 от 13 августа 2026 года. Сначала устанавливаем вход сравнения, затем выбираем разрешённый алгоритм и представление результата.
hash-source допускает SHA-256, SHA-384 и SHA-512. Запись ожидаемого хеша даёт один путь допуска кода, а не полную оценку безопасности страницы.
Для встроенного скрипта берётся текст программы после обработки HTML и кодирования UTF-8. Окружающие теги не входят в этот вход; значимые пробелы и переводы строк сохраняются.
В алгоритме хеша встроенного кода символ «-» заменяется на «+», а «_» на «/». Nonce сравнивается как строка и не получает этого преобразования.
Что означает совпавший хеш?
Разделяем допуск кода политикой и оценку самого кода. Особое внимание — сочетанию хешей с общим разрешением встроенного содержимого.
Nonce или хеш в эффективном списке отменяет общий допуск unsafe-inline этого списка. Совпадающий элемент при этом может быть разрешён собственным nonce или хешем.
Совпадение хеша не проверяет безопасность программы и не очищает недоверенный HTML. CSP дополняет контекстное кодирование и исправление точки внедрения, а не заменяет их.
Какая директива принимает решение?
Назовите вид проверки до чтения списка разрешений. Специальный запрет и отсутствие специальной директивы — разные состояния.
script-src-elem применяется к запросам и блокам скриптов, script-src-attr — к обработчикам событий в атрибутах.
При отсутствии специальной директивы переходят к script-src, затем к default-src. Это упорядоченный выбор внутри одной политики, а не объединение списков.
Присутствующая script-src-attr заменяет общую script-src для обработчиков. Специальный запрет не отменяется общим разрешением unsafe-inline.
Если специальная проверка запретила действие, алгоритм не ищет более разрешительную запасную только из-за отказа.
script-src-elem не управляет проверками unsafe-eval и не служит запасной для worker-src. Разрешение обычного скрипта не описывает весь JavaScript.
Кому передаётся решение о зависимостях?
strict-dynamic меняет значение списка узлов для скриптов. Проверяем не только исходный nonce, но и код, который выбирает дальнейшие адреса.
Допущенный по nonce или хешу загрузчик может создавать зависимости вне HTML-парсера без перечисления каждого узла в политике.
В этой ветви загрузки скриптов strict-dynamic не использует узлы, схемы, self и unsafe-inline как прежние разрешения. Адрес CDN рядом с ним не ограничивает программно созданные зависимости.
document.createElement создаёт элемент вне парсера; document.write вставляет через парсер. Второму способу без собственного допуска не достаётся то же разрешение.
Если злоумышленник управляет адресом программно создаваемого скрипта, правильно разрешённый загрузчик может загрузить нежелательную программу.
Для вставленного парсером запроса без совпавшего nonce или подходящих данных целостности ветка strict-dynamic запрещает загрузку; один адрес узла в списке не помогает.
Разрешён ли текст или доказан желаемый запуск?
Исследуем исключение для старых обработчиков. Разрешение программы и доказательство того, кто и как вызвал действие, остаются разными задачами.
unsafe-hashes расширяет сопоставление хеша на обработчики и другие названные алгоритмом встроенные контексты. Обычный хеш script сам этого не делает.
Nonce применяется к элементам script и style, а не к обработчикам в атрибутах. Nonce на кнопке не создаёт такой допуск.
Хешируется текст обработчика, например вызов функции, а не целый HTML-элемент. Изменённый текст требует новой проверки соответствия.
Совпавший текст не связан автоматически с желаемым событием. При допускающей политике чувствительный вызов может быть перенесён в другой контекст исполнения.
Пояснение CSP рекомендует избегать unsafe-hashes в новых страницах. Допуск старого обработчика не делает его безопасной точкой для непроверенных данных.
Достаточно ли одного совпавшего хеша внешнего файла?
Ограничиваем задачу допуском именно по hash-source. Другие разрешающие ветви, такие как подходящий nonce, в примерах исключены.
CSP сначала сопоставляет метаданные integrity с политикой. Проверку полученных байтов выполняет механизм целостности ресурса отдельно.
Каждый распознанный хеш integrity должен присутствовать среди разрешённых; набор должен быть непустым. Один неразрешённый распознанный хеш даёт отказ всей этой ветви.
При отсутствии или пустом разборе integrity ветка хешей не совпадает, даже когда ожидаемый хеш есть в заголовке.
Нераспознанные значения не участвуют в сравнении. Однако только невалидные записи не создают требуемого непустого набора.
У встроенного и внешнего варианта визуально того же кода может различаться вход хеширования. Хеш нельзя переносить без проверки представления байтов.
Кто встраивает страницу и где должна быть политика?
Не смешиваем загрузку дочерних страниц с ограничением внешних контейнеров защищаемого документа.
frame-ancestors ограничивает предков, которые встраивают ресурс. Разрешения на собственные дочерние страницы задаются в другом направлении.
Для frame-ancestors нет подстановки default-src. Общий запрет загрузок не становится запретом внешнего встраивания.
frame-ancestors в meta игнорируется. Для этой директивы проверяем политику, доставленную с HTTP-ответом.
Достаточно ли разрешить непосредственный контейнер?
Проверяем цепочку вложения целиком и условие взаимодействия CSP с X-Frame-Options в модели документа.
Алгоритм проверяет каждого предка. Если непосредственный родитель разрешён, но внешний контейнер не совпадает с политикой, проверка даёт запрет.
Значения 'none' и 'self' примерно соответствуют DENY и SAMEORIGIN. Наличие frame-ancestors в блокирующей политике заставляет модель игнорировать X-Frame-Options; режим только отчётов не выполняет это условие.
Какая политика действительно остановила действие?
Результат одной директивы не описывает весь набор ограничений. Отделяем блокирующие политики от наблюдения.
CSP задаёт правила загрузки и исполнения содержимого; для конкретного действия нужно определить применимые директивы.
Content-Security-Policy-Report-Only наблюдает нарушения, но сама эта политика не блокирует действие.
Действие должно удовлетворять каждой блокирующей политике. Более широкое разрешение во второй не отменяет запрет первой.
Что остаётся проверить после совпадения nonce?
Завершаем практику точными границами уже принятого механизма nonce. Длина значения, число элементов и доверие к разметке проверяются отдельно.
Браузер сопоставляет значение элемента с nonce-source политики. Это проверка допуска, а не анализ безопасности самого кода.
Новое значение создают для каждого ответа и выдают только разрешённым элементам.
Рекомендация — не менее 128 бит случайности до кодирования. Количество печатных символов не равно числу случайных битов.
Одно значение ответа может разрешать несколько подготовленных элементов. Оно не расходуется после первого скрипта.
Автоматическое проставление правильного nonce внедрённым элементам разрешает и их. Граница доверенного построения документа остаётся обязательной для выбранного решения.
Проверьте инженерное мышление
Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.
Источники курса
Ссылки приведены один раз для всего курса, чтобы не мешать чтению каждого тезиса.
- Первичная спецификация
Content Security Policy Level 3
World Wide Web Consortium · W3C Working Draft, 13 August 2026
Прочитана сохранённая локальная HTML-копия. Алгоритмы разделов 6–7 отделены от ненормативных примеров раздела 8; редакция проекта не означает проверку поддержки каждого браузера.
Открыть первоисточник - Официальная документация
Cross Site Scripting Prevention Cheat Sheet
OWASP Foundation · OWASP Cheat Sheet Series, checked 30 August 2026
Определяет context-specific output encoding и safe sinks; CSP и WAF рассматривает как дополнительные, а не основные XSS controls.
Открыть первоисточник - Первичная спецификация
Content Security Policy Level 3
World Wide Web Consortium · W3C Working Draft, 5 May 2026
Определяет CSP directives, source lists, nonce-source и browser enforcement для загрузки и исполнения content.
Открыть первоисточник