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

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

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

Content Security Policy

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

Content-Security-Policy: default-src 'self'; img-src 'self' https://pixinlink.ru; 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 — аудит зависимостей