API Anahtarlarını .env Dosyasına Koymak Yeterli mi? Secret Yönetiminin Doğru Yolu

Kısa özet .env dosyası API anahtarlarını source code içine yazmaktan çok daha iyi bir yöntemdir; özellikle local development için kullanışlıdır. Ancak production secret yönetimi yalnızca “anahtarı Git’e koymadık” seviyesinde bırakılmamalıdır.

Gerçek bir secret yönetimi sistemi şu soruları da cevaplamalıdır:

• Secret’ı kim okuyabilir?

Hangi environment kullanabilir?

Hangi uygulama veya repository erişebilir?

Anahtarın yetkileri ne kadar geniş?

Secret ne zaman döndürüldü?

Sızarsa nasıl iptal edilir?

Kullanıldığında audit kaydı oluşuyor mu?

CI/CD gerçekten uzun ömürlü credential saklamak zorunda mı?

OWASP, environment variable’ların process’ler, loglar veya sistem dump’ları üzerinden görünür hale gelebileceğine dikkat çekiyor ve daha güçlü secret injection yöntemleri mümkünse onların kullanılmasını öneriyor. AWS Secrets Manager ise erişim politikası, rotation ve audit gibi secret yaşam döngüsü kontrolleri sağlıyor. (OWASP Cheat Sheet Series)

Kısa doğrudan cevap

Local geliştirmede .env.local veya benzeri Git tarafından ignore edilen bir dosya genellikle yeterli olabilir. Production’da ise .env dosyasını tek başına secret yönetim sistemi olarak görmek doğru değildir. Daha sağlıklı yapı: Local Development → .env.local → düşük yetkili development key CI/CD → GitHub Environment Secret veya → OIDC / kısa ömürlü token Production → Platform Sensitive Environment Variable veya → Secret Manager Application → yalnızca gerekli secret'a erişim Operations → rotation + audit + revocation En önemli prensip: Secret’ı source code’dan çıkarmak ilk adımdır; secret’ın yaşam döngüsünü yönetmek asıl problemdir.

.env dosyası aslında ne yapıyor?

Basit olarak:

DATABASE_URL=postgresql://...
OPENAI_API_KEY=...
STRIPE_SECRET_KEY=...

gibi değerleri uygulama kodundan ayırır. Kod:

const apiKey = process.env.API_KEY

şeklinde kullanabilir. Bunun avantajı: Kod ≠ Credential ayrımının oluşmasıdır. Aynı uygulama:

• development,
• staging,

production ortamlarında farklı credential kullanabilir. Next.js de .env dosyalarının default create-next-app projelerinde .gitignore içine eklendiğini ve bu dosyaların neredeyse hiçbir zaman repository’ye commit edilmemesi gerektiğini açıkça belirtiyor. (Next.js)

.env neden hâlâ faydalı?

.env yaklaşımının kendisi kötü değildir. Özellikle local development için oldukça pratiktir. Örneğin: Developer laptop ↓ .env.local ↓ Development API modeli basit ve anlaşılırdır. Burada önemli olan:

• .env.local Git’e girmemeli,
• development credential kullanılmalı,

production credential local bilgisayarlara gereksiz yere dağıtılmamalıdır. Asıl problem .env değil, secret lifecycle eksikliği

Bir .env dosyasına anahtar koyduğunuzda şu sorular çoğu zaman cevapsız kalır:

• Kim kopyaladı?

Kim okuyabiliyor?

Ne zaman değiştirildi?

Hangi sunucularda bulunuyor?

Eski anahtar hâlâ aktif mi?

Sızdı mı?

Kim kullandı?

Secret manager sistemleri tam olarak bu nedenle kullanılır. Örneğin AWS Secrets Manager:

• secret saklama,
• IAM ile access control,
• rotation,

audit işlevleri sunar. AWS CloudTrail da Secrets Manager API çağrılarını ve rotation olaylarını kaydedebilir. (AWS Dokümantasyonu)

Secret nedir, environment variable nedir?

Bu ikisi aynı kavram değildir. Secret Hassas değerdir. Örneğin: Database password API private key Webhook signing secret OAuth client secret JWT signing key Environment variable Değerin uygulamaya iletilme yöntemlerinden biridir. Örneğin: Secret Manager ↓ Runtime ↓ Environment Variable ↓ Application olabilir. Dolayısıyla: “Environment variable kullanıyorum” ile “secret manager kullanıyorum” birbirini dışlayan şeyler değildir. Secret manager değeri güvenli biçimde yönetebilir ve uygulamaya runtime sırasında environment variable olarak aktarabilir.

.env dosyasını Git'e koymamak yeterli mi?

Hayır. İlk önemli kontrol budur ama tek kontrol değildir. Şu dosyanın: .env .gitignore içinde olması önemlidir. Fakat secret şuralardan da sızabilir: Terminal history Slack mesajı Screenshot CI log Error log Docker image Build artifact Browser bundle Backup Developer laptop Dolayısıyla secret güvenliği yalnızca Git probleminden ibaret değildir. OWASP environment variable’ların başka process’ler, logs veya system dumps üzerinden açığa çıkabileceğine dikkat çekiyor. (OWASP Cheat Sheet Series)

Yanlışlıkla Git'e gönderilen secret'ı .gitignorea eklemek sorunu çözer mi?

Hayır. Örneğin:

Commit 1

→ API_KEY eklendi

Commit 2

→ .env .gitignore'a eklendi yaptıysanız secret geçmiş commit içinde hâlâ bulunabilir. Bu durumda ana prensip: Secret sızmış kabul edilmeli ve credential rotate/revoke edilmelidir. Sadece dosyayı silmek yeterli değildir. GitHub push protection, desteklenen secret türlerinin repository’ye gönderilmeden önce tespit edilip push’un bloklanmasını sağlayabiliyor. (GitHub Docs) GitHub ayrıca secret scanning ve push protection’ı credential sızıntılarını azaltmak için temel organizasyon güvenlik kontrolleri arasında gösteriyor. (GitHub Docs)

Secret sızdıysa ne yapılmalı?

Önerilen sıra:

1. Credential'ı revoke / rotate et

↓

2. Yeni secret oluştur

↓

3. Secret store'u güncelle

↓

4. Uygulamayı redeploy/restart et

↓

5. Eski credential'ın gerçekten çalışmadığını doğrula

↓

6. Git/log/artifact kapsamını incele

↓

7. Kullanım kayıtlarını kontrol et

En önemli hata:

Önce Git history temizleyip credential’ı sonra değiştirmek. olabilir. Öncelik credential’ın kötüye kullanımını durdurmak olmalıdır.

Secret rotation neden önemli?

Uzun ömürlü bir API anahtarı:

2024 oluşturuldu ↓ 2025 kullanıldı ↓ 2026 hâlâ aynı ise sızdığı takdirde uzun süre geçerli kalabilir. Rotation: Eski secret ↓ Yeni secret ↓ Uygulama geçişi ↓ Eski secret revoke sürecidir. AWS Secrets Manager otomatik rotation destekliyor ve rotation işlemlerinin başlangıç, başarı veya hata durumlarını CloudTrail üzerinden kaydedebiliyor. (AWS Dokümantasyonu)

Her secret 30 günde bir değiştirilmek zorunda mı?

Hayır. Secret rotation sıklığı:

• credential türüne,
• sağlayıcının özelliklerine,
• risk seviyesine,
• kullanım biçimine,

compliance gereksinimlerine bağlıdır. Daha önemli hedef: Rotation yapılabilir bir sistem kurmak. Bir credential değiştirildiğinde 14 farklı sunucudaki .env dosyasını manuel düzenlemeniz gerekiyorsa rotation operasyonel olarak zorlaşır. Merkezi secret yönetiminin avantajlarından biri budur. Daha iyi seçenek: Uzun ömürlü secret hiç oluşturmamak Bazı sistemlerde en güvenli secret: saklamak zorunda olmadığınız secret’tır. Örneğin GitHub Actions bir cloud provider’a deploy edecekse klasik yöntem: GitHub Secret ↓ AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY ↓ AWS olabilir. Bu credential uzun ömürlüdür. GitHub OIDC ile ise: GitHub Actions ↓ OIDC ↓ Cloud Provider ↓ Short-lived Token kullanılabilir. GitHub, OIDC sayesinde cloud credential’larını uzun ömürlü GitHub secrets olarak saklamak yerine job için kısa ömürlü token alınabileceğini belirtiyor. (GitHub Docs) AWS de workload’larda mümkün olduğunda uzun ömürlü access key yerine IAM role tabanlı temporary credentials kullanılmasını öneriyor. (AWS Dokümantasyonu) Uzun ömürlü credential ile kısa ömürlü credential farkı Özellik Uzun ömürlü API Key Kısa ömürlü Credential Manuel revoke gerekebilir Evet Genellikle expire olur Secret store gerekir Çoğunlukla Her zaman değil Sızıntı etkisi Uzun olabilir Süre sınırlı Rotation Manuel/otomatik Doğal lifecycle CI/CD için Kullanılabilir Genellikle daha iyi

Bu nedenle özellikle cloud deployment tarafında:

API key saklamak yerine workload identity / OIDC kullanabilir miyiz?

sorusu sorulmalıdır.

Frontend'e API key koyabilir miyim?

Bu soruda en kritik ayrım:

• API key gerçekten secret mı?

Bazı servislerin özellikle browser veya mobile uygulamalarda kullanılmak için tasarladığı publishable/public key türleri vardır. Bunların görünmesi beklenen davranıştır. Ancak private credential: DATABASE_PASSWORD ADMIN_API_KEY SERVICE_ROLE_KEY PRIVATE_API_SECRET gibi değerler browser bundle’a girmemelidir.

Next.js'te NEXT_PUBLIC_ ne anlama geliyor?

Next.js’te:

API_SECRET=super-secret

server tarafında kalabilir. Ancak:

NEXT_PUBLIC_API_SECRET=super-secret

yazarsanız değer build sırasında client JavaScript bundle’ına inline edilir. Next.js resmî dokümantasyonu NEXT_PUBLIC_ değişkenlerin browser’a gönderilen JavaScript içine build-time’da hard-code edildiğini açıkça belirtiyor. (Next.js) Yani: NEXT_PUBLIC_ şu anlama gelir: Bu değerin kullanıcı tarafından görülebileceğini kabul ediyorum. Secret anlamına gelmez. Çok kritik Next.js hatası: next.config.js env Aşağıdaki yapı da dikkat gerektirir:

module.exports = {

env: {

• API_SECRET: process.env.API_SECRET,
• },

} Next.js dokümantasyonuna göre next.config.js içindeki env yapılandırmasıyla tanımlanan değerler JavaScript bundle’a dahil edilir; burada NEXT_PUBLIC_ prefix’i güvenlik sınırı oluşturmaz. (Next.js) Dolayısıyla private secret’ları: next.config.js → env üzerinden istemci koduna taşımamak gerekir.

Server-only kod kullanmak neden önemli?

Next.js server ve client component yapısında bazı modüller yanlışlıkla client’a import edilebilir. Örneğin:

export async function getData {
return fetch(API_URL, {

headers: {

• authorization: process.env.API_KEY,
• },

}) } gibi server-only fonksiyonlar client component tarafından kullanılmamalıdır. Next.js bu tür yanlış kullanımları azaltmak için server-only paketini öneriyor. (Next.js) Örneğin:

import 'server-only'
export async function getPrivateData {
// server-only credentials

} yaklaşımı kullanılabilir.

Production'da .env yerine ne kullanılabilir?

Tek bir doğru cevap yoktur. Proje altyapısına göre dört seviye düşünülebilir. Seviye 1 — Local .env Uygun:

• local development,

kişisel development credential. Seviye 2 — Hosting Platform Environment Variables Örneğin:

• Vercel environment variables,
• GitHub Actions secrets,

cloud platform config. Seviye 3 — Dedicated Secret Manager Örneğin:

• AWS Secrets Manager,
• cloud provider secret store,

Vault benzeri sistem. Seviye 4 — Workload Identity / Short-Lived Token Mümkünse uzun ömürlü credential tamamen kaldırılır.

Vercel environment variable kullanmak .envden daha mı güvenli?

Production operasyonu açısından daha kontrollü olabilir. Vercel environment variables:

• source code dışında tutulur,
• environment bazında ayrılabilir,

at-rest encryption kullanır. Vercel ayrıca sensitive environment variable özelliğiyle belirli secret’ların oluşturulduktan sonra dashboard’dan tekrar okunamamasını sağlayabiliyor. (Vercel) Örneğin: Development → Development DB Preview → Test DB Production → Production DB ayrılabilir.

Vercel environment variable değerleri production, preview ve development hedeflerine göre ayrı yönetilebiliyor. (Vercel)

Development ve production aynı API key'i kullanmalı mı?

Genellikle hayır. Şu model: Development Preview Production ↓ Aynı API Key blast radius’ı büyütür. Daha iyi: Development → low privilege dev key Preview → staging key Production → production key modelidir. Böylece developer laptop’taki bir leak doğrudan production sistemini etkilemeyebilir.

Preview environment production secret'a ulaşmalı mı?

Varsayılan olarak gerektiği varsayılmamalıdır. Preview deployment:

• feature branch,
• deneysel kod,
• dış contributor,

henüz review edilmemiş PR çalıştırabilir. Dolayısıyla production credential’ın preview’a verilmesi ciddi risk yaratabilir.

Vercel environment scope sistemi production, preview ve development değerlerinin ayrılmasını destekliyor. (Vercel)

GitHub Actions secrets nasıl kullanılmalı?

GitHub Actions:

• organization,
• repository,

environment seviyesinde secret tanımlayabiliyor. Organization secret’ları belirli repository’lerle sınırlandırılabilir. Environment secret’larda required reviewer tanımlanırsa workflow job, onay verilmeden secret’a erişemez. (GitHub Docs) Bu özellikle: Production deployment için güçlü bir modeldir. Örneğin: PR merge ↓ CI ↓ Production environment ↓ Human approval ↓ Production secrets accessible ↓ Deploy Secret'ın varlığı ile yetkisi ayrı problemdir Diyelim ki: STRIPE_SECRET_KEY güvenli secret store’da. Bu hâlâ: gereğinden fazla yetkili olabilir.

Secret management iki ayrı sorunu çözmelidir:

• Secret nerede?

+

Secret ne yapabilir?

Örneğin yalnızca read gerektiren uygulamaya:

Admin credential vermek doğru değildir. Prensip: Minimum secret + minimum permission.

Her servis ayrı credential kullanmalı mı?

Çoğu production sisteminde bu iyi bir yaklaşımdır. Riskli: Backend Worker Reporting Admin Cron ↓ Aynı DB admin credential Daha kontrollü: API → application role Reporting → read-only role Worker → limited write role Migration → migration role Böylece bir credential sızdığında etki alanı küçülür.

Secret Manager ne zaman gerçekten gerekli?

Özellikle şu durumlarda değeri artar:

• çok sayıda production secret varsa,
• birden fazla servis kullanıyorsa,
• çok sayıda ekip erişiyorsa,
• rotation gerekiyorsa,
• audit gerekli ise,
• multi-environment sistem varsa,
• compliance gereksinimleri varsa,

mikroservis mimarisi büyüyorsa. Küçük bir kişisel web sitesiyle 40 servisli SaaS sistemi aynı secret altyapısına ihtiyaç duymayabilir. .env, Platform Env ve Secret Manager karşılaştırması Özellik .env Platform Env Secret Manager OIDC / Identity Source code dışında ✅ ✅ ✅ ✅ Local geliştirme kolaylığı ✅ Orta Orta Değişir Merkezi access control ❌ ✅ ✅ ✅ Environment scope Manuel ✅ ✅ ✅ Audit ❌ Platforma göre ✅ ✅ Automated rotation ❌ Sınırlı ✅ Doğal/short-lived Uzun ömürlü secret gerekir ✅ ✅ ✅ Genellikle ❌ Büyük sistem için uygunluk Düşük Orta/Yüksek Yüksek

Yüksek

Secret'ları environment variable olarak vermek tamamen yanlış mı?

Hayır. Burada gereksiz bir mutlaklık kurmamak gerekir. Birçok hosting platformu secret’ları runtime’a environment variable olarak inject eder. Ancak OWASP’ın işaret ettiği risk şudur: Environment variable:

• diğer process’ler tarafından görülebilir,
• diagnostic dump içine girebilir,

yanlışlıkla loglanabilir. Bu nedenle yüksek güvenlik gerektiren sistemlerde:

• mounted file,
• secret agent,
• runtime fetch,

identity-based access

gibi modeller değerlendirilebilir. (OWASP Cheat Sheet Series)

Secret'ı startup'ta mı, her istekte mi okumalı?

Mimariye bağlıdır. Startup fetch App starts ↓ Secret Manager ↓ Secret memory Avantaj:

• düşük secret manager request maliyeti,

hızlı runtime. Dezavantaj: rotation sonrası process refresh gerekebilir. Runtime fetch + cache Request ↓ Secret cache ↓ gerektiğinde refresh Avantaj: rotation daha dinamik. Dezavantaj: cache ve availability tasarımı gerekir. Tek bir evrensel doğru yoktur.

Secret rotation sırasında downtime nasıl önlenebilir?

Birçok sistemde kısa süreli iki-key modeli kullanılabilir. Örneğin: Old Key + New Key geçici olarak birlikte kabul edilir.

Akış:

1. Yeni key oluştur

2. Uygulamayı yeni key'e geçir

3. Yeni key'in çalıştığını doğrula

4. Eski key'i revoke et

Bu yaklaşım provider destekliyorsa kesintisiz rotation sağlar.

Secret loglamak neden tehlikeli?

Şu kod:

console.log(process.env) çok tehlikeli olabilir. Aynı şekilde: console.error({

• error,
• config,
• apiKey,

}) secret’ı:

• log platformuna,
• telemetry sistemine,

error tracker’a gönderebilir. GitHub Actions bazı bilinen secret formatlarını loglarda otomatik redakte edebiliyor, ancak bu bütün hassas verilerin otomatik olarak güvenli hale geldiği anlamına gelmez. (GitHub Docs) Temel kural: Secret’ı loglamayın; masking’i ikinci savunma katmanı olarak görün.

Secret'ı base64 encode etmek şifrelemek midir?

Hayır. Örneğin:

echo "my-secret" | base64 yalnızca encoding’dir. Değer kolayca geri çevrilebilir. Base64 ≠ Encryption Secret’ı config dosyasına base64 şeklinde koymak onu güvenli hale getirmez.

Docker image içine secret koymak neden tehlikeli?

Örneğin: ENV API_KEY=super-secret veya build argument üzerinden hard-code edilen credential image metadata/layer veya build sürecinde sızıntı riski oluşturabilir. OWASP Docker secret yönetiminde secret’ın ENV veya ARG ile image tanımına hard-code edilmemesini öneriyor. (OWASP Cheat Sheet Series) Tercih edilen: Image → secret içermez Deployment runtime → secret inject eder modelidir. API key ismine bakarak public/private karar vermeyin Şu değişken: NEXT_PUBLIC_API_KEY sırf isminde PUBLIC olduğu için güvenli hale gelmez.

Doğru soru:

Sağlayıcı bu credential’ın public client’larda görünmesini tasarlamış mı?

olmalıdır. Eğer servis: secret key private key service role key admin token diyorsa browser veya mobil client içine gömülmemelidir.

Frontend'in private API'ye erişmesi gerekiyorsa ne yapılmalı?

Yanlış:

Browser ↓ Private Provider API ↓ Secret Key browser'da Daha güvenli: Browser ↓ Kendi Backend / Route Handler ↓ Server-side Secret ↓ Provider API Böylece secret browser'a verilmez. Ancak backend endpoint’in kendisi:

• authentication,
• authorization,
• rate limit,

input validation ile korunmalıdır. Aksi halde secret gizli olsa bile endpoint açık proxy’ye dönüşebilir.

Secret scanning pipeline'a eklenmeli mi?

Evet. Özellikle ekip büyüdükçe insan hatasını kabul etmek gerekir. GitHub Secret Scanning ve Push Protection: Developer commit ↓ Secret detected ↓ Push blocked / alert modelini sağlayabilir. (GitHub Docs) Ancak secret scanner: secret manager’ın alternatifi değildir. Biri sızıntıyı yakalar, diğeri secret lifecycle’ını yönetir.

Secret envanteri tutulmalı mı?

Production sistemlerde evet. Örneğin: Secret Owner Environment Scope Rotation Son Kontrol DB App User Backend Prod DB app 90 gün 01.08 Payment API Billing Prod Payment Provider 10.08 Email API Backend Prod Send only 180 gün 12.08 Böylece: “Bu key kimin ve silersek ne bozulur?” sorusu cevaplanabilir.

Secret lifecycle nasıl düşünülmeli?

Sağlıklı secret yönetimi:

CREATE

↓ STORE ↓ DISTRIBUTE ↓ USE ↓ MONITOR ↓ ROTATE ↓

REVOKE

↓

DELETE

döngüsüdür. .env yalnızca bu zincirin: STORE / DISTRIBUTE bölümünün küçük bir kısmını çözer. Secret Yönetim Kontrol Listesi Local development .env.local Git tarafından ignore ediliyor. Production key localde kullanılmıyor. Developer başına ayrı credential mümkünse kullanılıyor. Development credential düşük yetkili. Frontend Private key NEXT_PUBLIC_ altında değil. Private secret client bundle’a girmiyor. next.config.js env içinde private credential yok. Public/publishable key ile private key ayrımı yapıldı. Server-only modüller gerektiğinde işaretlendi. Repository Secret scanning aktif. Push protection değerlendirildi. .env.example gerçek credential içermiyor.

Commit history’de bilinen leak bulunmuyor.

CI/CD Secrets workflow dosyasına hard-code edilmiyor. Repository erişimleri minimum. Production secret environment seviyesinde tutuluyor. Production environment approval değerlendirildi. Cloud deployment için OIDC mümkün mü kontrol edildi. Production Development/Preview/Production secret’ları ayrılmış. Sensitive platform variables kullanılıyor. Dedicated secret manager ihtiyacı değerlendirildi. Secret’lar minimum permission taşıyor. Farklı servisler gereksiz yere aynı credential’ı kullanmıyor. Rotation Her secret’ın owner’ı belli. Revocation yöntemi biliniyor. Rotation prosedürü test edildi. Eski credential gerçekten revoke ediliyor. Emergency rotation prosedürü var. Audit Secret erişimi mümkünse loglanıyor. Secret değerinin kendisi loglanmıyor. Unusual access izleniyor. Eski/unused credential düzenli temizleniyor.

Hangi proje için hangi seviye yeterli?

Küçük kurumsal site

Şu model yeterli olabilir: Local → .env.local Production → Hosting platform env Git → secret scanning SaaS ürünü Daha güçlü: Local dev credentials + Environment separation + Platform secret storage + CI environment secrets + Rotation + Audit Büyük veya hassas B2B sistem Daha uygun: Central Secret Manager + IAM/RBAC + Temporary credentials + OIDC/workload identity + Automatic rotation + Audit + Incident process InoviqLab teknik değerlendirmesi Bu bölüm InoviqLab değerlendirmesidir; OWASP, GitHub, AWS, Vercel veya Next.js’in normative dokümantasyonundan ayrıdır. Secret management konusunda en sık yapılan hata: “.env Git'te değil, dolayısıyla güvendeyiz.” varsayımıdır. .env önemli bir development pratiğidir. Ancak production güvenliğinin hedefi yalnızca: Secret source code'da değil olmamalıdır. Daha güçlü hedef: Secret mümkün olduğunca az yerde bulunuyor + Mümkün olduğunca az kişi erişiyor + Mümkün olduğunca az yetkili + Mümkün olduğunca kısa ömürlü + Ne zaman kullanıldığı izlenebilir + Gerekirse hızlı revoke edilebilir olmalıdır. En önemli prensip: secret sayısını azaltmak Bir organizasyonda: 120 uzun ömürlü API key yönetmek yerine bazı entegrasyonların: OIDC IAM Role Workload Identity Short-lived token ile çalışması mümkünse gerçek risk alanı küçülür. AWS ve GitHub’ın temporary credential/OIDC önerileri de bu yönü destekliyor. (AWS Dokümantasyonu) Bu nedenle secret yönetiminde ilk soru: “Bu anahtarı nereye kaydedelim?”

• değil;

“Bu uzun ömürlü anahtara gerçekten ihtiyacımız var mı?” olmalıdır. İkinci prensip: production secret, development convenience uğruna yayılmamalı Bir developer’ın local ortamında production database credential bulunuyorsa:

• laptop compromise,
• terminal log,
• yanlış script,
• AI coding agent,

backup gibi çok daha fazla erişim yolu oluşur. Local geliştirme: local service veya development credentials kullanmalıdır. Production credential production boundary içinde tutulmalıdır. Üçüncü prensip: secret yönetimi bir DevOps özelliği değil, uygulama mimarisidir Credential:

• API,
• database,
• CI/CD,
• third-party service,
• AI agent,

cloud arasında dolaşır. Bu nedenle secret management yalnızca .env hazırlayan developer’ın görevi değildir. Mimari karar olarak:

• ownership,
• environment separation,
• permission,
• rotation,

audit tasarlanmalıdır. Dördüncü prensip: browser'da görünen değer secret değildir Frontend tarafında çok basit bir test kullanılabilir: Kullanıcının browser DevTools ile görebileceği bir değer, private secret olarak tasarlanmamalıdır. Next.js’in NEXT_PUBLIC_ davranışı bunun iyi bir örneğidir: değer build-time’da JavaScript bundle içine gömülür. (Next.js)

Sonuç

.env dosyası yanlış bir yöntem değildir. Ama secret management sisteminin tamamı da değildir. Local development için: .env.local + .gitignore + development key çoğu zaman yeterli olabilir. Production için ise: Environment separation + Platform secret storage veya Secret Manager + Least privilege + Rotation + Audit gereklidir. CI/CD tarafında ise mümkün olduğunda: Long-lived secret yerine: OIDC + Short-lived credential daha güçlü bir model sunabilir. (GitHub Docs) Özetle secret yönetiminin olgunluk sırası: Hard-coded key ❌ .env + gitignore ↓ Platform environment secret ↓ Central secret manager ↓ Short-lived workload identity şeklinde düşünülebilir. En güçlü prensip ise şudur: Bir secret’ı en güvenli saklama yolu, mümkünse o uzun ömürlü secret’a hiç ihtiyaç duymamaktır.