Заголовки безпеки HTTP: CSP, HSTS, Permissions-Policy та повна конфігурація

Вони не є брандмауером і не виправляють зламану авторизацію, вразливі API, SQL-ін'єкції, витік облікових даних чи застарілі залежності. Заголовки безпеки - це рівень глибокого захисту: вони зменшують поверхню атаки браузера й обмежують те, що може статися після того, як інша слабкість уже була використана.

У 2026 році корисно розділити три категорії:

1. Базові заголовки, які мають сенс для більшості вебсайтів.
2. Заголовки, що залежать від архітектури, які можуть зламати OAuth, платежі, CDN, iframe чи доставку PDF, якщо копіювати їх без аналізу.
3. Застарілі заголовки, які не слід вмикати лише для того, щоб покращити оцінку застарілого сканера.

TL;DR: почніть з ретельно спроєктованої політики Content Security Policy, HSTS після повного розгортання HTTPS, X-Content-Type-Options: nosniff, явного Referrer-Policy та стриманого Permissions-Policy. Використовуйте CSP frame-ancestors як основний засіб проти вбудовування у фрейми, а X-Frame-Options залишайте лише як рівень сумісності. Розгортайте COOP, COEP і CORP тільки після перегляду міжоригінних інтеграцій. Видаліть або вимкніть X-XSS-Protection, Expect-CT, HPKP і старий заголовок Report-To.

Рекомендації та сумісність востаннє перевірено 23 липня 2026 року.

Основні заголовки коротко

Заголовок	Типова рекомендація	Що обмежує	Використовувати всюди?
Content-Security-Policy	політика, специфічна для застосунку, бажано на основі nonce або hash	XSS, ін'єкції, незатверджені джерела ресурсів і вбудовування у фрейми	так, для HTML, після тестування
Strict-Transport-Security	max-age=31536000; includeSubDomains; додавайте preload лише після перевірки	пониження до HTTP та обхід помилок сертифікатів	так, коли весь домен готовий до HTTPS
X-Content-Type-Options	nosniff	MIME-сніфінг і частина плутанини з MIME	так
Referrer-Policy	strict-origin-when-cross-origin або суворіше	витік шляху та параметрів запиту URL	так
Permissions-Policy	вимкнення невикористовуваних можливостей, наприклад camera=(), microphone=(), geolocation=()	використання окремих API браузера документами й фреймами	зазвичай так, після тестування функцій
CSP frame-ancestors	'none', 'self' або явні джерела	клікджекінг і небажане вбудовування у фрейми	так, для HTML-документів
X-Frame-Options	DENY або SAMEORIGIN для сумісності	вбудовування у фрейми в старіших реалізаціях	часто, разом із frame-ancestors
Cross-Origin-Opener-Policy	часто same-origin, якщо не потрібні зв'язки зі спливаючими вікнами	частина XS-Leaks і доступ через window.opener	залежить від архітектури
Cross-Origin-Embedder-Policy	require-corp або credentialless, лише свідомо	вбудовування міжоригінних ресурсів без дозволу	ні, не автоматично
Cross-Origin-Resource-Policy	same-origin, same-site або cross-origin для кожного ресурсу	небажане міжоригінне читання без CORS	залежить від ресурсу
Cache-Control	no-store для дуже конфіденційних відповідей; private для персоналізованого вмісту	зберігання в кеші браузера й проміжних кешах	для конфіденційних відповідей
Set-Cookie	Secure; HttpOnly; SameSite=Lax/Strict залежно від потреби	крадіжка й недоречне міжсайтове надсилання файлів cookie	для сеансових файлів cookie
Reporting-Endpoints	кінцева точка для звітів CSP/COOP/COEP	спостережуваність політики	необов'язково
X-XSS-Protection	пропустити або встановити 0	застарілий фільтр XSS	не вмикати
Expect-CT	видалити	застарілий механізм Certificate Transparency	ні
Public-Key-Pins	не використовувати	історичне закріплення сертифікатів	ні

OWASP розглядає заголовки відповідей як цінні засоби посилення захисту, водночас наголошуючи, що кожне значення має відповідати типу відповіді та архітектурі застосунку.

Мінімальна відправна точка

Це стартовий шаблон, а не універсальна відповідь для копіювання й вставлення:

Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

Ця політика блокує вбудовані скрипти й стилі, джерела ресурсів, яких немає в переліку, вбудовування у фрейми, форми, що надсилаються до інших джерел, доступ до камери/мікрофона/геолокації та HTTP-навігацію після збереження HSTS.

Якщо сайт використовує зовнішні шрифти, аналітику, карти, платіжні віджети, OAuth, менеджери тегів, сторонні API або вбудований код, політику потрібно адаптувати.

1. Content-Security-Policy: найпотужніший і найскладніший заголовок

Content-Security-Policy визначає, звідки браузер може завантажувати скрипти, стилі, зображення, шрифти, фрейми та мережеві з'єднання. Правильний CSP може суттєво зменшити вплив XSS і впровадження даних, але не замінює перевірку вхідних даних, кодування вихідних даних і безпечні API DOM.

Основні директиви

Директива	Призначення	Типове початкове значення
default-src	резервне значення для типів ресурсів без окремої директиви	'self'
script-src	дозволені скрипти	nonce або hash, необов'язково 'self'
style-src	дозволені стилі	'self', nonce або hash
img-src	зображення	'self' data: https:
font-src	шрифти	'self' та явні джерела CDN
connect-src	Fetch, XHR, WebSocket і EventSource	ваш API та явні кінцеві точки
frame-src	фрейми, вбудовані сторінкою	лише потрібні джерела
frame-ancestors	які батьківські сторінки можуть вбудовувати цю сторінку	'none' або 'self'
form-action	дозволені призначення форм	'self' або явні кінцеві точки
base-uri	дозволені URL для <base>	'self' або 'none'
object-src	плагіни <object> та <embed>	'none'
upgrade-insecure-requests	перезапис HTTP-підресурсів на HTTPS	без значення

Списки дозволів проти суворого CSP

Список дозволених доменів може стати ненадійним. Довірений CDN може розміщувати багато не пов'язаних між собою файлів, а сторонній завантажувач може динамічно підтягувати додаткові залежності. web.dev рекомендує суворий CSP на основі nonce або hash; strict-dynamic дозволяє скриптам, завантаженим довіреним скриптом, успадкувати довіру.

Приклад політики з nonce:

Content-Security-Policy:
  default-src 'self';
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'none';
  form-action 'self';
  script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic';
  style-src 'self' 'nonce-{RANDOM_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  upgrade-insecure-requests

Відповідний HTML:

<script nonce="{RANDOM_NONCE}">
  window.__APP_CONFIG__ = { apiUrl: "https://api.example.com" };
</script>

Nonce має бути непередбачуваним, унікальним для кожної HTML-відповіді, присутнім у заголовку та довірених елементах і згенерованим сервером. Постійний nonce, збережений у конфігурації, не забезпечує очікуваного захисту. Для статичних сторінок, які не можуть генерувати нове значення для кожного запиту, практичнішими можуть бути hash.

Уникайте unsafe-inline та unsafe-eval

'unsafe-inline' у script-src дозволяє вбудований JavaScript і значно послаблює захист від XSS. 'unsafe-eval' вмикає API, що виконують рядки як код, зокрема eval() і конструктор Function.

Не додавайте їх лише для того, щоб приховати порушення в консолі. Натомість:

1. перенесіть вбудований код у зовнішні файли;
2. використовуйте nonce або hash;
3. визначте залежність, якій потрібен eval;
4. пошукайте іншу конфігурацію збірки або бібліотеки.

Trusted Types

Політика на кшталт:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy

може вимагати типізованих значень у певних місцях DOM XSS, як-от innerHTML. Починаючи з лютого 2026 року, require-trusted-types-for доступний у поточних основних браузерах, хоча старіші випуски можуть його не підтримувати.

Trusted Types - це просунутий захист. Застосунок має визначити безпечні політики перетворення, а фреймворки й залежності мають бути сумісними. Самого лише додавання заголовка недостатньо.

Почніть із Report-Only

Безпечніше розгортання починається з:

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/security/csp-reports"

Content-Security-Policy-Report-Only повідомляє про порушення, не блокуючи ресурси, що дає змогу виявити відсутні джерела та зламані процеси до застосування політики. Reporting-Endpoints замінює застарілий заголовок Report-To і йому слід надавати перевагу для поточних розгортань.

Кінцева точка звітування має застосовувати обмеження розміру корисного навантаження, обмеження частоти, безпечне журналювання, кодування вихідних даних і короткий, цільовий термін зберігання. Звіти CSP можуть містити URL-адреси та відомості про ресурси.

2. Strict-Transport-Security: HTTPS без шляху пониження

HSTS повідомляє браузеру, що зв'язок із хостом має відбуватися лише через HTTPS. Після збереження браузер підвищує майбутні HTTP-спроби до HTTPS і не дає користувачам обходити деякі помилки сертифікатів.

Strict-Transport-Security: max-age=31536000; includeSubDomains

• max-age=31536000 зберігає політику протягом одного року.
• includeSubDomains охоплює субдомени.
• preload вказує на намір приєднатися до списку preload браузера.

Не починайте з preload

Неправильне розгортання HSTS може заблокувати доступ легітимним користувачам. Старий субдомен лише з HTTP, прострочений сертифікат або сторонній сервіс під вашим доменом можуть зробити includeSubDomains і тривалий max-age небезпечними.

Обережне розгортання може використовувати:

5 minutes → 1 day → 1 week → 1 month → 1 year

На кожному етапі тестуйте кореневий домен, активні субдомени, сертифікати wildcard і SAN, застарілі сервіси, адміністративні панелі, API та партнерські кінцеві точки.

HSTS preload вимагає дійсного сертифіката, перенаправлень з HTTP на HTTPS, достатньо тривалого max-age, includeSubDomains і токена preload. Видалення може тривати тижнями, оскільки список постачається всередині браузерів.

3. X-Content-Type-Options: припиніть вгадування MIME

X-Content-Type-Options: nosniff

Це вказує браузеру дотримуватися оголошеного Content-Type, а не переінтерпретувати відповідь як інший тип. Скрипти та стилі можуть блокуватися, коли їхній тип MIME не відповідає очікуваному.

Це не замінює правильну конфігурацію сервера. Відповіді все одно потребують точних значень:

Content-Type: text/html; charset=utf-8
Content-Type: text/css; charset=utf-8
Content-Type: application/javascript; charset=utf-8
Content-Type: application/json; charset=utf-8
Content-Type: image/avif

Це особливо важливо для файлів, завантажених користувачами, кінцевих точок завантаження, динамічно згенерованих файлів, об'єктного сховища, CDN і відповідей з помилками, які можуть повертати HTML замість JSON.

4. Referrer-Policy: зменшення витоку URL

Referrer-Policy контролює, яка частина URL поточної сторінки може надсилатися в заголовку Referer під час запиту іншого ресурсу.

Розумне значення за замовчуванням:

Referrer-Policy: strict-origin-when-cross-origin

Воно надсилає повний URL для запитів того самого джерела, лише джерело для міжоригінних HTTPS-запитів і не надсилає реферер під час пониження з HTTPS до HTTP.

Суворіші альтернативи включають:

Referrer-Policy: no-referrer

або:

Referrer-Policy: same-origin

Цей вибір може вплинути на аналітику, партнерські системи та платіжних провайдерів. Секрети, токени, адреси електронної пошти та персональні дані взагалі не варто розміщувати в URL-адресах.

5. Захист від клікджекінгу: frame-ancestors та X-Frame-Options

Найгнучкіший засіб - це CSP:

Content-Security-Policy: frame-ancestors 'none'

або:

Content-Security-Policy: frame-ancestors 'self' https://portal.partner.example

frame-ancestors визначає, які батьківські сторінки можуть вбудовувати документ у <frame>, <iframe>, <object> чи <embed>.

Для сумісності додайте:

X-Frame-Options: DENY

або:

X-Frame-Options: SAMEORIGIN

MDN рекомендує frame-ancestors для сучасних розгортань, оскільки він виразніший. ALLOW-FROM застарів і може призвести до того, що сучасні браузери ігноруватимуть заголовок. X-Frame-Options має бути HTTP-заголовком; версія через <meta http-equiv> не має жодного ефекту.

6. Permissions-Policy: вимкнення можливостей, які сайт не використовує

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Заголовок контролює доступ документа та його фреймів до окремих можливостей браузера, зокрема камери, мікрофона й геолокації.

Дозволити поточне джерело:

Permissions-Policy: geolocation=(self), camera=(), microphone=()

Або дозволити явне джерело:

Permissions-Policy: geolocation=(self "https://maps.example")

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

7. COOP, COEP і CORP: міжоригінна ізоляція не є універсальним значенням за замовчуванням

Ці заголовки пов'язані, але вирішують різні завдання.

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy: same-origin

COOP контролює, чи документи, відкриті через навігацію або window.open(), спільно використовують групу контексту перегляду. same-origin відокремлює документ від міжоригінних відкривачів і пом'якшує деякі XS-Leaks.

Це може зламати спливаючі вікна OAuth, платіжні вікна та інтеграції, що покладаються на window.opener. У деяких випадках доречніше таке:

Cross-Origin-Opener-Policy: same-origin-allow-popups

Cross-Origin-Embedder-Policy

Cross-Origin-Embedder-Policy: require-corp

COEP вимагає, щоб міжоригінні ресурси no-cors надавали дозвіл через CORP або завантажувалися з CORS. Відсутні заголовки можуть блокувати зображення, шрифти, скрипти, фрейми та інші сторонні ресурси.

Альтернатива:

Cross-Origin-Embedder-Policy: credentialless

Це дозволяє деякі ресурси no-cors без явного CORP, водночас видаляючи облікові дані, як-от файли cookie.

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy: same-origin

CORP - це політика самого ресурсу, яка може використовувати:

• same-origin,
• same-site,
• cross-origin.

Це не заміна CORS. MDN також документує проблему Chrome, пов'язану з частковим відображенням PDF за деяких розгортань CORP, тому заголовок не слід застосовувати глобально без тестів.

Пара:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

вмикає міжоригінну ізоляцію, потрібну для окремих просунутих API, зокрема повного доступу до SharedArrayBuffer. Не розгортайте її лише заради оцінки сканера.

8. Безпечні файли cookie та кешування

Set-Cookie і Cache-Control не завжди зараховують до заголовків безпеки, але вони безпосередньо захищають сеанси та конфіденційні дані.

Сеансовий файл cookie

Set-Cookie: __Host-session=RANDOM_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure обмежує передавання лише HTTPS.
• HttpOnly запобігає доступу з JavaScript.
• SameSite обмежує міжсайтове надсилання.
• __Host- вимагає Secure, Path=/ і відсутності Domain, тісніше прив'язуючи файл cookie до хоста.

SameSite=Strict суворіший, але може порушувати повернення від провайдерів входу чи оплати. SameSite=None вимагає Secure і має використовуватися лише для дійсно міжсайтового файлу cookie.

Конфіденційні відповіді

Cache-Control: no-store

Це просить приватні та спільні кеші не зберігати відповідь. Персоналізований вміст, який можна кешувати в браузері, але не проміжними вузлами, може використовувати:

Cache-Control: private, no-cache

MDN рекомендує явно позначати персоналізовані відповіді як private, щоб уникнути випадкового спільного кешування.

9. Зменшення розкриття технологій

Заголовки на кшталт:

Server: nginx/1.24.0
X-Powered-By: PHP/8.4
X-AspNet-Version: 4.0.30319

полегшують створення відбитка. Їх видалення не приховує стек від рішучого зловмисника, але дає змогу уникнути прямого розкриття версій.

• видаліть X-Powered-By;
• вимкніть заголовки версій фреймворку;
• обмежте деталі в Server;
• не публікуйте навмисно неправдиву версію;
• не плутайте маскування з усуненням уразливостей.

OWASP рекомендує видаляти X-Powered-By й обмежувати Server, зазначаючи водночас, що технології все одно можна визначити іншими способами.

10. Застарілі заголовки та оманливі поради

X-XSS-Protection

Не вмикайте:

X-XSS-Protection: 1; mode=block

OWASP попереджає, що застарілі фільтри XSS можуть створювати уразливості на інакше безпечних сторінках. Пропустіть заголовок або явно вимкніть його:

X-XSS-Protection: 0

Натомість використовуйте CSP, кодування вихідних даних і безпечні API.

Expect-CT

Expect-CT на практиці застарів, оскільки сучасні клієнти вимагають Certificate Transparency для сучасних сертифікатів. MDN описує його як значною мірою застарілий з червня 2021 року.

Public-Key-Pins

HPKP не слід розгортати. Неправильний pin може надовго заблокувати доступ користувачам, а заголовок було видалено із сучасних браузерів. Надавайте перевагу правильному TLS, автоматичному поновленню, CAA, моніторингу сертифікатів і ретельно переглянутому HSTS preload.

Report-To

Старий:

Report-To: { ... }

застарів. Використовуйте:

Reporting-Endpoints: csp="https://example.com/reports/csp"

Access-Control-Allow-Origin: *

CORS - це не набір заголовків посилення захисту, який можна додати глобально. Access-Control-Allow-Origin послаблює політику одного джерела (Same-Origin Policy). Відповіді API з обліковими даними не можуть безпечно поєднувати символ підстановки * з автентифікованим міжоригінним доступом. Дозволяйте лише потрібні джерела й перевіряйте їх на боці сервера.

11. Приклади конфігурації сервера

Nginx

add_header Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header X-Frame-Options "DENY" always;

always має значення, оскільки зберігає заголовки у відповідях з помилками та нестандартними статусами.

Apache

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set X-Frame-Options "DENY"
</IfModule>

PHP

<?php

header("Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests");
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");
header("Permissions-Policy: camera=(), microphone=(), geolocation=()");
header("X-Frame-Options: DENY");

Заголовки потрібно надсилати до тіла відповіді. Генеруйте криптографічно випадковий nonce окремо для кожного запиту.

Node.js / Express

app.use((req, res, next) => {
  res.setHeader(
    "Content-Security-Policy",
    "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  );
  res.setHeader(
    "Strict-Transport-Security",
    "max-age=31536000; includeSubDomains"
  );
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
  res.setHeader(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
  );
  res.setHeader("X-Frame-Options", "DENY");
  res.removeHeader("X-Powered-By");
  next();
});

Сайту, що використовує CDN, WebSocket, OAuth, платежі чи карти, знадобиться ширший, але все одно явний CSP.

12. Процес розгортання, що уникає збоїв

Інвентаризація

Перелічіть усі джерела скриптів, стилів, шрифтів і зображень; кінцеві точки API та WebSocket; iframe; спливаючі вікна OAuth/оплати; ресурси CDN; файли, завантажені користувачами; субдомени HSTS та можливості браузера, які використовує застосунок.

Спостереження

• запустіть CSP у режимі Report-Only;
• збирайте звіти та порушення в консолі браузера;
• протестуйте кожен критичний шлях користувача;
• охопіть мобільні та підтримувані браузери;
• перевірте сторінки помилок, перенаправлення та статичні ресурси.

Застосовуйте поступово

• почніть з object-src, base-uri, frame-ancestors і form-action;
• перейдіть до статичних ресурсів;
• суворий script-src застосовуйте останнім;
• поступово збільшуйте max-age HSTS;
• тестуйте COOP/COEP окремо на спливаючих вікнах і міжоригінних інтеграціях.

Відстежуйте регресії

Тести CI мають отримувати репрезентативні URL-адреси, виявляти дубльовані чи конфліктні заголовки, підтверджувати типи MIME, виявляти випадкове видалення CSP/HSTS і виконувати наскрізні процеси входу та оплати.

13. Як тестувати заголовки

Перевірте відповідь безпосередньо:

curl -I https://example.com/

Слідуйте за перенаправленнями:

curl -IL https://example.com/

Перевірте конкретний ресурс:

curl -I https://example.com/assets/app.js

Перевірте заголовки на головній сторінці, під час входу, у відповідях 404 і 500; переконайтеся, що CSP не дублюється з конфліктними політиками; переконайтеся, що HSTS надсилається лише через HTTPS; перевірте типи MIME; і переконайтеся, що CDN або зворотний проксі не видалив заголовки.

Безкоштовний інструмент POLPROG Security Headers Inspector перевіряє HSTS, CSP, захист від вбудовування у фрейми та інші засоби. Використовуйте DNS & SSL Inspector для перевірки сертифікатів і DNS, а Website Health Check - для ширшого огляду SEO, продуктивності, доступності та безпеки.

Контрольний список розгортання

CSP

• Обмежувальний default-src.
• object-src 'none'.
• Обмежений base-uri.
• frame-ancestors відповідає реальній моделі вбудовування.
• form-action обмежує призначення форм.
• Вбудований код використовує nonce або hash за потреби.
• Nonce унікальний для кожної відповіді.
• Немає невиправданого 'unsafe-inline'.
• Немає невиправданого 'unsafe-eval'.
• Політику спершу протестовано в режимі Report-Only.
• Кінцева точка звітування має обмеження частоти й обмежений термін зберігання.

HTTPS та HSTS

• Кожна сторінка й ресурс працюють через HTTPS.
• HTTP перенаправляє безпосередньо на HTTPS.
• Сертифікати відстежуються.
• Усі субдомени інвентаризовано.
• max-age збільшено поетапно.
• includeSubDomains безпечний.
• preload додано лише після розгляду наслідків.

Інші засоби

• X-Content-Type-Options: nosniff.
• Правильний Content-Type у кожній відповіді.
• Явний Referrer-Policy.
• Permissions-Policy вимикає невикористовувані можливості.
• Немає ALLOW-FROM у X-Frame-Options.
• COOP не ламає OAuth чи платежі.
• COEP не блокує потрібні сторонні ресурси.
• CORP відповідає моделі спільного використання кожного ресурсу.
• Сеансові файли cookie використовують Secure, HttpOnly і відповідний SameSite.
• Конфіденційні відповіді використовують правильний Cache-Control.
• Заголовки версій технологій видалено.
• X-XSS-Protection відсутній або вимкнений.
• Expect-CT, HPKP і старий Report-To видалено.

Висновок

Для більшості бізнесових вебсайтів і вебзастосунків правильний порядок такий:

1. Правильні HTTPS, типи MIME та безпечні файли cookie.
2. Специфічний для застосунку CSP, розгорнутий через Report-Only.
3. HSTS, розгорнутий поетапно.
4. nosniff, Referrer-Policy, Permissions-Policy та захист від вбудовування у фрейми.
5. COOP, COEP і CORP лише тоді, коли зрозуміла міжоригінна модель.
6. Видалення застарілих заголовків і заголовків, що розкривають інформацію.

Найкращий набір заголовків безпеки - не найдовший. Це найменша політика, яка точно відповідає застосунку, витримує тестування критичних шляхів і залишається під наглядом після кожного розгортання.