Защита токенов, API‑ключей и секретов

Публичный? Приватный? Что?

Когда защищать токены?

Защита API‑ключей и токенов критически важна!

Одна ошибка может привести к потере контроля над сервером и данными в руки хакеров!

Определять, должен ли конкретный токен быть скрыт, не должно быть сложно — даже опираясь на официальную документацию!

Ситуацию только усложняет «суп» из связанных терминов, с которыми вы сталкиваетесь: tokens, keys, credentials, secrets, private и public.

Переформулируем это как различие между secret и non-secret.

🔒 Secret keys ДОЛЖНЫ оставаться скрытыми. Как правило, они НИКОГДА не должны покидать ваш приватный сервер (или сервис — вроде heroku, netlify или travis-ci).
🌍 Non-secret keys описывают строки, которые можно свободно делиться и включать в запросы браузера.

🔒 `Secret keys`

** ‼️ Важно:** Secret keys ДОЛЖНЫ игнорироваться Git‑ом И исключаться из любого кода, исполняемого в браузере. Как использовать dotenv

Как понять, что вы имеете дело с Secret key?

👍 Ориентир: серверы, которые возвращают ошибки CORS, не поддерживают работу из браузера. Это сильный сигнал, что их НАДО проксировать, рассматривая их как secret.

👍 Ориентир: дорогостоящие сервисы почти всегда следует проксировать или скрывать.

👍 Ориентир: если вы выполняете операцию записи (загрузка файла, вставка строки в БД), вероятно, имеете дело с secret keys.

Сценарии использования и возможности: Secret‑ключи

Долгосрочная авторизация (учётные данные, токены доступа, JSON Web Tokens)
Краткосрочная авторизация (OAuth‑токены, хранилище сессий)
Доступ к платным/дорогим сервисам (аутентификация, геокодинг, хранение файлов и пр.)
Приватная часть пары публичный/приватный (RECAPTCHA, Stripe, Auth0)
Учётные данные сервисов (Email/SMTP, LDAP/службы каталогов)
Шифрование данных и проверка целостности

Чек‑лист: безопасное обращение с секретами

Краткий обзор

Выполните следующие шаги, чтобы удалить секреты из кода:

Замените захардкоженные ключи переменными окружения, например process.env.API_SECRET
Используйте библиотеку вроде dotenv совместно с файлом .env. Перенесите ранее захардкоженные секреты в файл .env.
Добавьте строку .env в ваш файл .gitignore!

НЕ ДЕЛАЙТЕ создание файла .env на продакшн‑серверах. Пользуйтесь средствами управления переменными окружения, предоставляемыми вашим хостингом (например, Heroku, Netlify, AWS EC2): через панель управления или командную строку.

Связанная статья: Безопасное использование dotenv в NodeJS

🌍 `Non-secret keys`

👍 Правило‑навык: если ключ необходимо отправлять в браузер в коде или инлайн (например, через тег <script src="https://my-api/?apiKey=123-abc-456">), это однозначно non-secret. Типичный пример — Google Maps.

Сценарии применения и особенности: Non-secret‑ключи

Краткосрочный доступ (идентификаторы пользовательских сессий, JSON Web Token)
Ограничение доступа к API по приложению/разработчику (для аутентификации, геокодинга и т.п.)
Публичная часть пары «публичный/приватный» (RECAPTCHA, Stripe, Auth0)
Идентификаторы аналитики

✅ Обращение с non‑secret‑ключами:

Можно безопасно хардкодить non‑secret (публичные) ключи!

Упростите долгосрочное управление, вынеся их в общий config.js для вашего приложения.

Пример:

module.exports = {
  googleMapsKey: '123-abc'
};

const config = require('./config.js');
const key = config.googleMapsKey;
const src = `//maps.googleapis.com/maps/api/js?key=${key}`;
// ...

Примечание: Существуют и другие сценарии использования переменных окружения. Некоторые из них я не охватил: CI/CD/тестирование, флаги функций и конфигурация выполнения для специальных окружений!