Wiki
Безопасность

CSP — Content Security Policy простыми словами

CSP — HTTP-заголовок, задающий политику загрузки ресурсов страницы. Защита от XSS: браузер сам блокирует inline-JS и скрипты с чужих доменов.

Content Security Policy (CSP) — заголовок `Content-Security-Policy`, инструктирующий браузер: какие источники JS/CSS/изображений/шрифтов/фреймов разрешены. Хорошо настроенная CSP превращает XSS-уязвимость в неисполняемый мусор — атакующий смог вставить `<script>`, но браузер отказался запускать.

Пример стартовый: `Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.example.com; frame-ancestors 'none';`. Означает: JS — только со своего домена и cdn.example.com, CSS — с домена + inline (плохо), картинки — свои + любые https, API — только к api.example.com, не встраиваться в iframe.

Ключевые директивы: `default-src` (fallback), `script-src`, `style-src`, `img-src`, `font-src`, `connect-src` (XHR/fetch), `frame-src` (кого встраиваем), `frame-ancestors` (кто нас встраивает — clickjacking-защита), `form-action` (куда submit формы). Спец-значения: `'self'`, `'none'`, `'unsafe-inline'` (плохо), `'unsafe-eval'` (плохо), `nonce-<random>`, `sha256-<hash>`.

Внедрение: (1) `Content-Security-Policy-Report-Only` неделю — лог нарушений в console, ничего не блокируется, (2) чистим приложение (убираем inline JS в отдельные файлы, используем nonce), (3) переключаем на `Content-Security-Policy`. Ошибки логируем через `report-uri` / `report-to`.

Частые вопросы

'unsafe-inline' насколько плохо?
Практически убивает защиту от XSS (в 90 % случаев). Уходить от inline JS обязательно; inline CSS менее критично.
Как быть с Google Analytics?
`script-src 'self' https://www.googletagmanager.com; connect-src 'self' https://www.google-analytics.com;`

Смотрите также