Безопасность статических сайтов: CSP, HTTPS и защита секретов

2026-05-08by GitHub CMS Team2 min readDevOpssecurityssldeploymentcsp

Статические сайты безопаснее динамических по умолчанию: нет базы данных для SQL-инъекций, нет серверного кода для RCE, нет пользовательских сессий для перехвата. Но это не значит что безопасностью можно пренебречь. GitHub CMS включает несколько уровней защиты.

Уровни безопасности в GitHub CMS

Уровень Механизм Что защищает
Транспортный HTTPS (Let’s Encrypt) Перехват трафика
Контентный Content Security Policy XSS-атаки
Секретный GitHub Secrets + валидация Утечка API-ключей
Сборка check-dist-secrets Секреты в production-бандле
Деплой SSH + least-privilege Доступ к серверу
Рантайм Статические файлы (нет исполняемого кода) RCE, инъекции

Content Security Policy

CSP запрещает браузеру загружать ресурсы из недоверенных источников. Пример для GitHub CMS:

Content-Security-Policy: default-src 'self'; img-src 'self' https://pixinlink.com; script-src 'self'; style-src 'self' 'unsafe-inline'

CSP настраивается в nginx и блокирует inline-скрипты, внешние шрифты и изображения с непроверенных доменов.

Защита секретов

GitHub CMS блокирует попадание секретов в production на трёх этапах:

  1. Валидация контента — validate:content проверяет Markdown-файлы на паттерны секретов перед сборкой
  2. Сканирование бандла — check-dist-secrets проверяет все файлы в dist/ на утечку ключей
  3. GitHub Secrets — все приватные ключи хранятся только в GitHub Secrets и никогда не попадают в репозиторий

FAQ

Q: Достаточно ли HTTPS для безопасности статического сайта? A: HTTPS защищает трафик между сервером и браузером, но не защищает от XSS если вы используете inline-скрипты. Всегда добавляйте CSP.

Q: Как проверить что секреты не попали в production? A: Запустите npm run check:dist-secrets после сборки. В GitHub Actions эта проверка выполняется автоматически.

Q: Нужно ли обновлять зависимости? A: Да. Запускайте npm audit регулярно. Dependabot в GitHub автоматически создаёт PR для обновления уязвимых зависимостей.

Проверьте безопасность вашего сайта

  1. npm run validate:content — проверка контента на секреты
  2. npm run check:dist-secrets — проверка production-бандла
  3. npm audit — аудит зависимостей
Статические сайты безопаснее динамических по умолчанию: нет базы данных для SQL-инъекций, нет серверного кода для RCE, нет пользовательских сессий для перехвата. Но это не значит что безопасностью можно пренебречь. GitHub CMS включает несколько уровней защиты.
## Уровни безопасности в GitHub CMS | Уровень | Механизм | Что защищает | |---|---|---| | Транспортный | HTTPS (Let's Encrypt) | Перехват трафика | | Контентный | Content Security Policy | XSS-атаки | | Секретный | GitHub Secrets + валидация | Утечка API-ключей | | Сборка | check-dist-secrets | Секреты в production-бандле | | Деплой | SSH + least-privilege | Доступ к серверу | | Рантайм | Статические файлы (нет исполняемого кода) | RCE, инъекции | ## Content Security Policy CSP запрещает браузеру загружать ресурсы из недоверенных источников. Пример для GitHub CMS: ``` Content-Security-Policy: default-src 'self'; img-src 'self' https://pixinlink.com; script-src 'self'; style-src 'self' 'unsafe-inline' ``` CSP настраивается в nginx и блокирует inline-скрипты, внешние шрифты и изображения с непроверенных доменов. ## Защита секретов GitHub CMS блокирует попадание секретов в production на трёх этапах: 1. **Валидация контента** — `validate:content` проверяет Markdown-файлы на паттерны секретов перед сборкой 2. **Сканирование бандла** — `check-dist-secrets` проверяет все файлы в `dist/` на утечку ключей 3. **GitHub Secrets** — все приватные ключи хранятся только в GitHub Secrets и никогда не попадают в репозиторий

FAQ

## Проверьте безопасность вашего сайта 1. `npm run validate:content` — проверка контента на секреты 2. `npm run check:dist-secrets` — проверка production-бандла 3. `npm audit` — аудит зависимостей

Related Articles