📚 Теория: Нельзя хардкодить ключи (раскрыть)
Почему так делают?
Разработчик спешил и зашил ключ прямо в класс, чтобы «быстрее протестировать». В итоге ключ попадает в Git, логи и билды.
⚠️ Любой, у кого есть доступ к репозиторию или jar, видит секрет.
Чем это грозит?
Утечки API-ключей ведут к списанию средств, компрометации клиентов и блокировке поставщика.
🔐 Секреты должны храниться в Secret Manager, Vault или ENV.
Ключ попадает в Git и историю.
В jar/war ключ доступен любому QA или злоумышленнику.
Сервис-агрессор перехватывает ключ и совершает запросы от вашего имени.
Как надо: считывать ключ из переменных окружения, HashiCorp Vault, AWS Secrets Manager или Kubernetes Secrets. В коде должна быть лишь ссылка на источник, но не сам секрет.
Контекст
Сервис работает с биллингом и использует API ключ для аутентификации. Чтобы «упростить», разработчик сохранил ключ в поле класса, после чего код оказался в Git. Твоя задача — показать, почему это критично.
- Проверь, какие значения возвращает
buildHeaders(). - Пойми, как часто такой класс попадает в лог, билд и репозиторий.
- Подготовь рекомендации: как хранить и обновлять ключи правильно.
Сниппет
Code Review
Референс-фигура
Секреты нельзя хранить в репозитории. Правильный подход — считывать ключи из конфигурации/Secret Manager и валидировать наличие на старте.
Флаг ревью: FLAG{java-hardcoded-config-secret}
public class ConfigService {
private final String billingApiKey;
public ConfigService(Environment env) {
this.billingApiKey = env.getRequiredProperty("billing.api.key");
}
public Map<String, String> buildHeaders() {
return Map.of(
"Authorization", "Bearer " + billingApiKey,
"User-Agent", "RTLabs-Labs/1.0"
);
}
}Используй переменные окружения, Vault/KMS и обязательную ротацию. Для локальной разработки добавь sample-файл .env.example, но не сам секрет.
Проверка флага
После ревью зафиксируй флаг, чтобы дашборд засчитал лабораторию.