Security-заголовки без втрати видимості в AI

Додавання security-заголовків на власний сайт зламало перемикач мов і мало не заблокувало всіх AI-краулерів, яких ми професійно намагаємося привабити. Обидві проблеми ми створили собі самі, обидві були беззвучні, обидві легко повторити. Ось повний звіт.

Чому це взагалі виникає

Технічні аудити перевіряють кілька HTTP-заголовків відповіді: політику безпеки контенту, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy. Їхній прямий вплив на видимість в AI помірний, але вони є в кожному чеклисті технічної якості, а деякі статичні хостинги не вміють віддавати кастомні заголовки взагалі.

Стандартне рішення — поставити CDN-проксі перед хостингом і додати заголовки там. Це працює. І це відкриває дві пастки.

Пастка перша: проксі пропонує заблокувати AI-краулерів, і за замовчуванням — так

Під час налаштування наш CDN показав панель керування AI-ботами: пошукові краулери, агентські, тренувальні. Рекомендованим значенням для тренувальних було блокувати, з додатковим перемикачем — увімкненим за замовчуванням, — який автоматично вписує ці заборони в robots.txt.

Вдумайтеся. Наш robots.txt явно вітає кожного AI-краулера. Наш блог доводить, що бізнесу варто їх впускати. А інфраструктурний шар був за один клік від того, щоб перекреслити все це, тихо переписавши файл.

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

Що робити: після будь-якої зміни на CDN чи в безпеці запросіть власний robots.txt через публічний інтернет і прочитайте його. Не файл у репозиторії — той, який реально віддає ваш домен. Вони можуть відрізнятися, і з редактора цю різницю не видно.

Пастка друга: суворий CSP вбиває inline-обробники подій

Ми свідомо задали сувору політику безпеки контенту: script-src 'self' плюс один домен аналітики, без 'unsafe-inline'. Перевірили сайт на inline-блоки <script>, не знайшли жодного і випустили.

За два тижні перемикач мов перестав працювати.

Перемикач був <select onchange="location.href=this.value">. Атрибут-обробник події — це теж inline-скрипт, і та сама директива його блокує. Гучної помилки не буде. Обробник просто не реєструється: консоль чиста, елемент в інспекторі виглядає нормально, а на взаємодію нічого не відбувається.

Збій був ще й відкладеним. Код не змінювався тижнями; він зламався тієї миті, коли заголовки пішли в бій. У журналі деплою на причину не вказувало ніщо.

Правильне і неправильне виправлення. Спокуслива поправка — додати 'unsafe-inline' до script-src. Один рядок, усе працює, і ви щойно скасували головну користь від політики, яку встановлювали.

Правильна поправка — перенести обробник у наявний файл скрипта:

document.querySelectorAll("select.lang-select").forEach(function (sel) {
  sel.addEventListener("change", function () {
    if (this.value) location.href = this.value;
  });
});

Політика лишається суворою, функція працює. Inline-атрибути style не постраждали — style-src це окрема директива, і вона може зберігати 'unsafe-inline', не послаблюючи захист скриптів.

Як написати CSP, що не ламає ваш сайт

Політика, скопійована з чеклиста, заблокує щось потрібне. Наша мала пропустити три зовнішні джерела: скрипт аналітики, точку, куди він надсилає дані, і воркер, що приймає заявки з форм. Узагальнений default-src 'self' тихо вбив би і аналітику, і збір лідів.

Практична послідовність:

1. Складіть перелік того, що сторінки реально завантажують. Скрипти, шрифти, зображення і кожну точку, до якої звертається ваш JavaScript.
2. Прогрепайте шаблони на атрибути on*=. Кожен із них зараз перестане працювати.
3. Задеплойте і проклікайте живий сайт із відкритою консоллю. Кожне порушення друкує назву директиви — вона й підкаже, що додати.
4. Перевіряйте те, що надсилає, а не лише те, що відображається. Форми ламаються інакше, ніж макети.

Загальний висновок

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

Після будь-якої зміни на цьому рівні перевірте три речі з публічного інтернету: чи robots.txt читається як задумано, чи заголовки відповіді саме такі, як ви задали, і чи працюють інтерактивні елементи. Десять хвилин — і ви ловите саме той клас збоїв, який інакше залишається непоміченим місяцями.