Хранение паролей/токенов любого характера и толка в репозитории – плохая и опасная практика. Несмотря даже на то, что это информация может относиться к изолированному staging или даже локальному окружению. Даже если они “потом будут встроены в итоговый html”. Даже если пароль “явно выглядит как заглушка”. Наличие паролей “от staging-а” может легко привести к компрометации настроек “от prod-а”.
Как значения “для разработки” могут скомпрометировать значения “от prod-а”?
Да очень просто – коллега случайно запушит. Так что лучше вообще не показывать такой пример. Не нужно оправдывать свои действия фразами “но ведь эти значения только для локальной разработки”, аудиторам будет все равно при проверке исходников – поставят низкую оценку и будут правы. К тому же, средствам автоматической проверки тоже не объяснишь – они обнаруживаются и “ругаются” вне зависимости от того пароль от staging-а или нет, простой пароль/токен или сложный. Для автоматического сканера что 123456, что changeme и даже '' – непустое значение. Не стоит игнорировать такой сигнал от анализатора – лучше поступить как он советует и избавиться от хранения таких хардкодов в коде/конфигах.
Вместо этого – хранить настройки окружения на самом окружении (сервере в рамках внутренних переменных или настроек сессии) и/или недоступном для основной проектной команды месте (CI, Wiki, password manager, etc.) Отличной стратегией является хранение названий конфигурационных ключей в .env.example файле в репозитории, но без каких либо значений. Приложение при старте может/должно проверять целостность и полноту конфигурации (значения ключей) и “падать” при обнаружении проблем.
Я не считаю “правильным”, когда из конфигурационного (app.config например) файла убирают только те значения, которые “кажутся” относящимися к секретным – это не решает проблему. Разработчику для нормальной работы нужно все равно иметь их заполненными. И вероятность случайно вкомитить эти значения вместе с другим изменением конфига – весьма высока.
Что делать?
Применять старую проверенную стратегию “разделяй и властвуй”. Необходимо вынести значения, которые нежелательно иметь в основном конфигурационном файле из него в отдельное место. К примеру в .NET для этого предусмотрен специальный механизм. С помощью ConfigurationBuilder можно использовать параметры из переменных окружения, либо из внешних файлов, добавляемых к приложению на этапе доставки инструментами Continuous Integration.
А мы используем git crypt? Это норм?
Эта мера защитит вас от случая, когда исходники “украли” или кто-то посторонний получил к ним доступ. Но концептуально это проблему не решило. Используя шифрование конфигов вы постулируете – “нам есть что прятать”. Готов спорить, что если используете git crypt – значит и конфиги от production у вас в репозитории хранятся. Это требует доверия ко всем членам команды разработки. Может быть вы, как команда, готовы на это пойти. Однако не думаю, что заказчик (если бы его спросили об этом явно) будет с такой позицией согласен. Как минимум он будет против смены всех кредов после каждой ротации разработчика в его команде.
Но это было тут вкомичено еще до меня, и лишь только поменял/отформатировал…
Помните про формулировку из правовых документов – “любое действие или бездействие расценивается…” Увидели крамолу – не проходите мимо, оставьте после себя “лучше чем было”.
Но если в репозитории не будет значений, то новому разработчику будет сложнее “завести” систему
Противоречие тут только кажущееся, проблема не в том, что новому члену команды будет сложно, а в том, что процесс не понятен. Причем сделать его “понятным” можно даже без подробного README файла с описанием всех конфигурационных опций (это как комментарии в коде, которые быстро устаревают). Представьте, запускаете вы приложение, а оно вам сообщает – не найден такой-то конфигурационный файл. Понятно же ведь что необходимо сделать – создать его. Какой он должен быть? Попробую либо пустой, либо, если замечу рядом с ним .example файл – скопирую из .example файла содержимое. Запускаю еще раз – система все еще отказывается стартовать, сообщая что параметр STRIPE_API_KEY не может быть пустым. Опять – совершенно ясно что делать. Такой подход (когда приложение отказывается стартовать) сэкономит вам часы debug-а в случаях, когда после git pull окажется, что добавилось новое конфигурационное значение и система не может правильно работать, когда оно пустое. Можно, конечно, возразить “вооот, а если бы .env файл был в репозитории, проблемы бы не возникло”. Так-то оно так, только откуда автору знать – планируете ли вы использовать тот же STRIPE_API_KEY или у вас есть свой, а может быть я, для тестирования, использую ключ со staging-а и потом его вкомичу…
Подводя итог – не храните пароли/токены/ключи/сертификаты в репозитории.