Чекліст безпеки сайту: CSP, HSTS, заголовки

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

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

Навіщо маркетинговому сайту чекліст безпеки?

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

Наслідки зазвичай непоказні, але дорогі:

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

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

Багатошаровий щит: захист з’єднання, заголовки, форми й залежності як окремі рівні оборони

Транспорт: HTTPS усюди, потім HSTS

Кожна сторінка, ресурс і запит до API мають працювати через HTTPS. Перенаправляйте HTTP на HTTPS постійним редиректом і виправте всі попередження про змішаний вміст.

Далі додайте HTTP Strict Transport Security. HSTS наказує браузеру використовувати для вашого домену лише HTTPS протягом заданого часу, навіть якщо людина ввела http:// або перейшла за старим посиланням.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Вмикайте поступово. Почніть із короткого max-age, наприклад один день, і переконайтеся, що жоден піддомен не зламався. Потім збільште до одного-двох років. Додавайте preload і подавайте домен у список попереднього завантаження браузерів лише тоді, коли певні, що всі піддомени підтримують HTTPS. Вилучення зі списку займає багато часу.

Content Security Policy, яка справді працює

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

Сучасний підхід - сувора політика на основі nonce, а не довгий список дозволених доменів:

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

Сервер генерує новий випадковий nonce для кожної відповіді і додає його до кожного тегу script, якому довіряє. 'strict-dynamic' дозволяє цим скриптам підвантажувати власні залежності. Усе, що вбудовано без nonce, не виконується.

Як запровадити CSP і нічого не зламати:

Почніть у режимі звітів. Надсилайте Content-Security-Policy-Report-Only і тиждень-два збирайте звіти про порушення.
Складіть список сторонніх сервісів. Аналітика, чат-віджети, менеджери тегів, вбудоване відео. Щодо кожного потрібне свідоме рішення.
Посильте, потім вмикайте. Виправте або приберіть те, що показали звіти, і перейдіть на заголовок, який блокує.
Стежте після кожного релізу. Нові функції часто додають нові джерела.

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

У посібнику MDN про Content Security Policy детально пояснено кожну директиву.

Решта чекліста безпеки сайту: заголовки, які мають значення

Окрім HSTS і CSP, кілька заголовків закривають типові прогалини. Актуальний довідник веде OWASP Secure Headers Project.

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin
X-Frame-Options: DENY

X-Content-Type-Options: nosniff забороняє браузеру вгадувати тип файлу і блокує цілий клас атак через підміну типу вмісту.
Referrer-Policy обмежує, яка частина ваших URL потрапляє на інші сайти. strict-origin-when-cross-origin - розумне значення за замовчуванням.
Permissions-Policy вимикає функції браузера, якими сайт ніколи не користується, як-от камеру чи геолокацію.
Cross-Origin-Opener-Policy ізолює ваші сторінки від вікон, відкритих іншими сайтами.
X-Frame-Options захищає від клікджекінгу в старих браузерах. У сучасних те саме робить директива CSP frame-ancestors. Надсилайте обидва.

X-XSS-Protection не потрібен. Він застарів, сучасні браузери його ігнорують, а в деяких старих він сам створював проблеми.

Опублікуйте також файл /.well-known/security.txt за RFC 9116. Він підказує дослідникам безпеки, як повідомити вам про проблему.

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

Перевіряйте дані на сервері. Перевірки в браузері допомагають користувачам, але не захищають вас.
Обмежуйте частоту відправлень. Ліміт запитів з однієї IP-адреси уповільнює спам і зловживання.
Екрануйте вивід. Усе, що надсилає відвідувач, має відображатися як текст у листах, панелях і CMS.
Збирайте менше. Кожне непотрібне поле - це дані, які не доведеться захищати.
Ставте прапорці cookie. Сесійним cookie потрібні Secure, HttpOnly і значення SameSite.

Для акаунтів CMS і хостингу:

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

Залежності, хостинг і секрети

Більшість зламів використовують відомі вразливості, для яких уже є виправлення. Оновлення - найнудніший пункт цього списку і один із найважливіших.

Комітьте lock-файл. Збірка має встановлювати саме ті версії, які ви тестували.
Автоматизуйте сповіщення про оновлення. Dependabot чи Renovate позначають вразливі пакети. Хтось має відповідати за їх перегляд.
Оновлюйте фреймворк вчасно. У березні 2025 року Next.js розкрив CVE-2025-29927: вразливість, що дозволяла обійти перевірки авторизації в middleware. Виправлені версії вийшли швидко. Під ризиком лишилися сайти, які не оновилися.
Тримайте секрети поза репозиторієм. API-ключі зберігайте у змінних середовища хостингу, а не в коді чи клієнтських бандлах.
Робіть резервні копії й перевіряйте відновлення. Копія, яку ви жодного разу не відновлювали, - це надія, а не резервна копія.

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

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

Як перевірити свої налаштування

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

Проскануйте сайт у MDN HTTP Observatory, щоб перевірити заголовки й налаштування TLS.
Відкрийте консоль браузера на ключових сторінках і пошукайте порушення CSP та змішаний вміст.
Запустіть команду аудиту свого пакетного менеджера і перегляньте результати.
Спробуйте форми з неочікуваними даними: довгі рядки, HTML, швидкі повторні відправлення.
Повторюйте після кожного суттєвого релізу. Налаштування безпеки «розповзаються», коли їх ніхто не перевіряє.

Наступний крок: безпека з першого коміту

Кожен проєкт Kyvrel, зокрема розробка веб-застосунків і SaaS, за замовчуванням має HTTPS, HSTS, CSP на основі nonce, заголовки зі списку вище, форми з обмеженням частоти та файл security.txt. Веб-застосунок коштує від 25 000 $ за MVP на 15 екранів, типовий термін 12-16 тижнів. Наш тримісячний план супроводу за 1 500 $ покриває оновлення залежностей і патчі безпеки після запуску.

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