Секреты и защита данных
Ключи, токены и персональные данные - то, за чем реально охотятся атакующие. Защищай их при хранении, при передаче и в истории исходников.
Чек-лист
- Держи секреты вне кода и клиента. API-ключи, пароли к базам и signing-секреты должны жить в переменных окружения или в менеджере секретов, никогда не быть захардкоженными и никогда не отправляться в браузер. ИИ-инструменты часто вшивают ключи в клиентский код, поэтому прогони grep по бандлу на всё, что похоже на ключ.
- Держи секреты вне git. Добавь
.env,*.pemи*.keyв.gitignoreдо первого коммита. Всё, что когда-либо было закоммичено, скомпрометировано, даже если удалено позже, потому что остаётся в истории. Смени такой секрет. - Шифруй чувствительные данные при хранении. Используй аутентифицированное шифрование (AES-256-GCM) для хранимых секретов и чувствительного пользовательского контента, с ключом вне базы данных.
- Всё отдавай через TLS. Никакого открытого HTTP для всего, что несёт учётные данные или персональные данные. Перенаправляй HTTP на HTTPS и задавай HSTS.
- Не клади секреты и персональные данные в URL. Query string попадает в логи, историю браузера и заголовок Referer. Клади их в тело запроса.
- Возвращай минимум. Эндпоинт профиля или "me" должен возвращать только то, что нужно UI, и никогда не хеши паролей, ключи или внутренние флаги.
- Храни токены там, где скрипт их не достанет, когда это возможно. JWT в
localStorageчитается любым скриптом, поэтому XSS его украдёт. httpOnly cookie этого избегает (ценой необходимости обработки CSRF). В любом случае строгий Content-Security-Policy - твоя страховка. См. инфраструктуру. - Обеспечивай права на данные. Дай пользователям возможность экспортировать и удалять свои данные и очищай их по расписанию. Это и хорошая практика, и, для многих, юридическое требование.
Как тестировать
- Открой вкладку network в dev tools и JS-бандл; ищи
sk-,eyJ,password,secret,key. - Просканируй репозиторий и его историю сканером секретов.
- Вызови свой эндпоинт "me" и прочитай каждое поле, которое он возвращает.