Defaults.Exposed › Виправлення › Content-Security-Policy (CSP)

Як виправити Content-Security-Policy (CSP)

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

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

Що це може вам коштувати

• Прихований код потрапляє на одну з ваших сторінок і тихо копіює кожен номер картки і пароль, який вводять ваші клієнти на касі, надсилаючи їх зловмиснику, поки ваш сайт виглядає абсолютно нормально — ви дізнаєтесь лише коли надійдуть скарги на шахрайство.
• Шахрай розміщує на вашому справжньому сайті підроблену форму «оплатіть тут», що перехоплює платежі на його рахунок; клієнти вважають, що платили вам, звинувачують вас, коли товар не надходить, і вимагають повернення коштів.
• Служба безпеки великого клієнта сканує ваш сайт, бачить, що цей базовий захист вимкнений, і позначає це — зупиняючи або руйнуючи контракт, поки ви не доведете виправлення.
• Витік, пов'язаний з відсутністю стандартного захисного заходу, стає звітним інцидентом: запитання регулятора, повідомлення клієнтів і удар по репутації, що коштує набагато більше, ніж безкоштовне виправлення.

Чому це важливо. Замок підтверджує, що з'єднання з вашим сайтом є приватним, але нічого не робить для контролю того, який код запускається після того, як відвідувач на сторінці. Content Security Policy — це захист, який це робить: він каже браузерам ігнорувати будь-який скрипт, що не надійшов від джерела, якому ви довіряєте, тому єдине підроблене поле, реклама або плагін не може перетворитися на інструмент крадіжки грошей і даних ваших клієнтів. Це оцінюваний пункт у вашій картці результатів, вартий реальних балів, і одна з перших речей, яку шукає професійний огляд безпеки.

Що це таке — простими словами

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

Content Security Policy (часто скорочено CSP) — це короткий список правил, що ваш сайт прикріплює до кожної сторінки, кажучи браузеру: «запускай лише код із цих джерел, які я схвалив, і відмовляй від всього іншого». Це різниця між нічним клубом, що пускає всіх, і тим, що має список гостей біля дверей.

Причина, чому це настільки важливо: сайти постійно підроблюються — не завжди через злом вашого сервера, а через задні двері, які більшість сайтів залишають відкритими: поле коментаря, поле пошуку, застарілий плагін, сторонній скрипт для реклами або аналітики, чи чат-віджет. Якщо зловмисник отримує навіть один рядок свого власного коду на одну з ваших сторінок, браузер запускає його так, ніби він ваш. Звідти він може читати все, що вводять ваші клієнти — номери карток, паролі, адреси — і тихо надсилати це деінде. Content Security Policy закриває цю двері, відмовляючись запускати щось від джерела, якого ви не схвалили.

Що це може коштувати вам

Атака, яку запобігає Content Security Policy — код, вставлений на сторінку, що краде дані з ваших власних клієнтів — стоїть за деякими найбільшими витоками карткових даних у записах. Ось як це зазвичай відбувається для звичайного бізнесу:

• Невидимий скімер каси. Зловмисник вставляє кілька рядків коду на вашу сторінку каси через вразливий плагін або скомпрометований сторонній скрипт. Кожен номер картки, ім’я і CVV, що вводять ваші клієнти, копіюється і надсилається зловмиснику в реальному часі. Ваш сайт виглядає і працює ідеально; замок є. Ви дізнаєтесь про це через тижні, коли ваш платіжний провайдер дзвонить щодо кластера звітів шахрайства, що ведуть до вашого магазину. Тепер ви стикаєтесь із поверненнями, примусовим аудитом безпеки, можливою втратою прав на обробку карток і витоком, про який ви можете бути юридично зобов’язані повідомити.

• Підроблена форма оплати. Шахрай вставляє переконливе поле «оплатіть тут» на ваш справжній сайт. Клієнти вводять свої дані, довіряючи вашому бренду; гроші і дані йдуть до зловмисника. Клієнти звинувачують вас — і вони мають рацію, бо це сталося на вашому сайті.

• Втрачений контракт. Служба безпеки більшого потенційного партнера запускає автоматизоване сканування вашого сайту як частину перевірки постачальника. Відсутня Content Security Policy відразу з’являється як прогалина з високою серйозністю. Для закупівельника або рецензента безпеки єдиний відсутній захист читається як «цей постачальник не робить базових речей» — і угода зависає, поки вони просять про виправлення.

• Звітний витік. Коли витік даних простежується до відсутнього, стандартного, безкоштовного захисного заходу, він перестає бути невезінням і починає виглядати як недбалість. Це змінює запитання регулятора, зобов’язання щодо повідомлення клієнтів і вартість — як штраф, так і репутаційна шкода, що триває довго після закриття інциденту.

• Скомпрометована реклама або віджет. Багато сайтів завантажують код від зовнішніх сторін — рекламні мережі, шрифти, підтримку чату, аналітику. Якщо будь-яка з них буде зламана, шкідливий код прямо потрапляє на ваші сторінки. Content Security Policy обмежує радіус вибуху, дозволяючи лише конкретні зовнішні джерела, яким ви довіряєте, тому витік одного постачальника автоматично не стає вашим.

Що це насправді є (деталі)

Content Security Policy доставляється як один заголовок HTTP-відповіді — рядок, що ваш веб-сервер надсилає з кожною сторінкою. Його значення — набір директив, кожна з яких іменує тип контенту і дозволені для нього джерела. Наприклад:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Простими словами: за замовчуванням завантажуй лише речі мого власного сайту; запускай лише скрипти мого власного сайту; не дозволяй старих плагінів; і не дозволяй іншим сайтам вбудовувати мій у фрейм.

Як виглядає «добре». Наша перевірка не просто шукає присутність заголовку — вона читає політику директиву за директивою і оцінює, наскільки вона насправді є сильною. Сильна політика:

• Встановлює обмежену базу (default-src 'self') і розширює її лише для конкретних довірених третіх сторін, яких ви справді використовуєте.
• Уникає лазівок. Вона не використовує 'unsafe-inline' або 'unsafe-eval' для скриптів і не використовує шаблон (*) або схемні джерела (як https:) для скриптів. Де вбудовані скрипти дійсно необхідні, вона використовує nonce або хеш, щоб запускався лише ваш конкретний схвалений код.
• Блокує фреймування за допомогою frame-ancestors 'self' і відключає застарілі плагіни за допомогою object-src 'none'.
• Є режимом застосування, а не лише звітування. Заголовок Content-Security-Policy-Report-Only лише спостерігає; він не забезпечує жодного захисту в режимі реального часу. Наша перевірка дає йому невелику частку балів і ніколи не записує його як прохідне. Ви захищені лише після того, як політика є застосовуючою.

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

Як це виправити (безкоштовно, ~1–2 години)

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

1. Починайте в режимі лише звітування — не застосовуйте ще. Додайте заголовок відповіді Content-Security-Policy-Report-Only. Це спостерігає і реєструє, що буде заблоковано, не блокуючи нічого, тому живий сайт продовжує працювати, поки ви дізнаєтесь, від чого справді залежить кожна сторінка. (Важливо: лише звітування само по собі не дає відвідувачам жодного захисту — це лише безпечний перший крок.)

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

3. Уникайте лазівок, що знищують весь сенс. Утримуйтесь від 'unsafe-inline' і 'unsafe-eval' для скриптів та уникайте джерел-шаблонів, як * і голі схеми, як https: для скриптів. Де вбудовані скрипти неминучі, використовуйте nonce або хеш, щоб запускався лише ваш конкретний схвалений код.

4. Блокуйте фреймування і плагіни. Додайте frame-ancestors 'self' (це також зупиняє інші сайти від вбудовування вашого для обману ваших клієнтів) і object-src 'none'.

5. Перемикайтеся з лише звітування на застосування. Щойно звіти чисті і сайт працює, змініть ім’я заголовка з Content-Security-Policy-Report-Only на Content-Security-Policy. Це крок, що насправді забезпечує захист — одна лише політика звітування не забезпечує, і не пройде перевірку.

   Де встановлювати заголовок залежить від вашої платформи:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → встановіть Content-Security-Policy.
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): додайте власний заголовок HTTP-відповіді з іменем Content-Security-Policy і політикою як значенням.
   • Google Workspace / Microsoft 365: вони запускають вашу пошту, а не ваш публічний сайт, тому політика встановлюється там, де ваш сайт фактично розміщений (Cloudflare або ваш веб-хост вище), а не в консолі адміністратора пошти.

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

Поширені помилки

• Зупинитися на режимі лише звітування. Найпоширеніша помилка: політика додається в режимі лише звітування, всі рухаються далі, і сайт так ніколи насправді не захищається. Лише звітування нічого не блокує. Необхідно переходити до застосування.
• Звертатися до 'unsafe-inline', щоб «просто зробити так, щоб воно працювало». Коли політика блокує законний вбудований скрипт, швидке виправлення — дозволити всі вбудовані скрипти — але це знову відкриває саму дірку, яку покликана закрити політика. Замість цього використовуйте nonce або хеш.
• Використання шаблону. Голий * (або https:) у script-src дозволяє скрипти звідусіль, а це означає, що політика майже не дає реального захисту і все одно матиме низьку оцінку.
• Забування сторонніх джерел. Застосування суворої політики без попереднього переліку законних зовнішніх служб (аналітика, шрифти, платіжні віджети) може зламати частини вашого власного сайту — саме тому існує пробний крок лише звітування.
• Встановлення лише на головній сторінці. Політика повинна охоплювати кожну сторінку, особливо касу, логін і сторінки облікового запису — саме вони варті атаки.
• Сприйняття її як заміни замку. Content Security Policy і HTTPS/HSTS захищають різні речі. Вам потрібні всі; одна не замінює іншу.

FAQ