Vibe Coding Güvenlik Kontrolü: Yayından Önce 10 Madde

Kısa sonuç

• Vibe coding ile yazılmış bir uygulamada API anahtarı frontend kodunun içinde kalabilir. Anahtar, tarayıcının indirdiği sayfanın içindeyse herkese açıktır. Siteyi açan kişi onu okuyabilir ve sizin sağlayıcı hesabınızdan harcama yapabilir.
• Bunu görmek için güvenlik uzmanı olmanız gerekmez. Yayınlamadan önce kendi projenizde bakacağınız sabit bir liste yeter.
• Claude Code'da /security-review yazın. Yerleşik bir komuttur. Geçerli dalınız ile origin üzerindeki varsayılan dal arasındaki farka bakar; enjeksiyon, kimlik doğrulama ve veri ifşası gibi riskleri işaretler. Git deposu ve origin uzak adresi ister. Bulguları yazar, düzeltmeyi kendi kendine uygulamaz.
• Raporu okuyun, kabul ettiğiniz madde için Claude'dan düzeltme isteyin, değişikliği siz kontrol edin, komutu yeniden çalıştırın. Aşağıdaki on madde yerinde durur.

Bu vibe coding güvenlik kontrolü ne işe yarar

Vibe coding, uygulamayı tarif edip kodun büyük kısmını bir yapay zekâya yazdırmaktır. İlk çalışan ekran bir öğleden sonra gelebilir. Ziyaretçiye giden paketin içine yapışmış, ücretli bir API anahtarı da aynı hızla gelebilir.

Frontend'deki anahtar, paspasın altına bırakılmış ev anahtarıdır. Sayfa yabancılar yüklesin diye vardır. Sır oradaysa sır değildir.

Bu sayfa, reelin vaadinin adresidir. Yoruma KONTROL yazan buraya gelir. İş sizin projenizdedir: on kontrol, sonra yayına gidecek dalda /security-review. Bu bir başlangıç kiti değildir. /security-review de CodeBaseHub komutu değildir; Claude Code ile gelir.

Kurulan sitede anahtar nerede durur

Sağlayıcı anahtarı, tarayıcı onu hiç almıyorsa gizli kalır. Sunucu, değeri ortam değişkeninden okur ve sağlayıcıyı kendisi çağırır. Tarayıcı sizin sunucunuzu çağırır.

Sızıntı bunun tersidir. Anahtar bir istemci bileşenindedir, paketleyicinin içeri aldığı ortak bir ayardadır ya da NEXT_PUBLIC_, VITE_ veya EXPO_PUBLIC_ gibi herkese açık bir öneke yazılmıştır. Bu önekler, değerin istemci paketine gömülmesi için vardır. Sitenin adresi orada durabilir. Harcama yetkisi olan bir sır duramaz.

Üretim derlemesinden sonra sunucunun dağıtacağı çıktıyı arayın ve kendi yayındaki sayfanızı açın. Sayfa kaynağına ve tarayıcının indirdiği JavaScript'e bakın. Anahtar o yanıtın içindeyse herkese açıktır. Arama sizin derlemeniz içindir. Başkasının sitesini karıştırmak için bir yol değildir.

Son commit'ten satırı silmek yetmez. Eski commit, ekran görüntüsü veya sohbete yapıştırılmış metin değeri hâlâ taşıyorsa eski anahtar, sağlayıcı iptal edene kadar çalışır.

Yayından önce on madde

1. Anahtarlar yalnız sunucunun ortam değişkeninde

İstemci bileşenlerinde, paylaşılan frontend ayarında ve mobil ekranlarda uzun token ve tırnak içinde sağlayıcı sırrı arayın. İyi hali: sır yalnız sunucuda, herkese açık öneki olmayan bir ortam değişkeninden okunur. Tarayıcı sağlayıcıyı değil, sizin yolunuzu çağırır.

2. İstemci paketinde sır yok

Uygulamayı yayına çıktığı gibi derleyin. Çıktıda (dist, .next, build veya dışa aktarılmış web paketi) gerçek anahtarı arayın. Kaynakta, herkese açık olmaması gereken NEXT_PUBLIC_, VITE_ ve EXPO_PUBLIC_ değerlerine bakın. İyi hali: sır için sıfır eşleşme. Herkese açık değişkenlerde yalnız gösterilmesi zaten normal olan değerler vardır; site adresi ya da harcama yetkisi olmayan publishable istemci anahtarı gibi.

3. .env git'e girmemiş

Depo kökünde git ls-files çıktısını .env için süzün. Sonradan silinmiş olsa bile bir commit'in .env ekleyip eklemediğine bakın. İyi hali: git'in izlediği .env, .env.local veya .env.production yoktur. Boş değerli bir .env.example durabilir. Gerçek değerler makinede ya da barındırıcının sır deposunda kalır.

4. .gitignore sır dosyalarını kapsıyor

.gitignore içinde .env ve .env.* olsun. Yalnız .env.example izlenecekse ona istisna tanıyın. Kullandığınız kimlik dosyalarını da yazın (*.pem, hizmet hesabı JSON'u). Deneme için bir .env.local oluşturup git status bakın. İyi hali: git bu dosyayı commit'e önermez. Dosya izlendikten sonra eklenen kural, dosyayı izlemeden çıkarmadan işe yaramaz.

5. Git'e, ekran görüntüsüne veya sohbete düşmüş anahtarı yenileyin

Madde 3 veya 4 tutmuyorsa ya da anahtar bir slaytta, ekran kaydında veya kayıtta göründüyse onu herkese açık sayın. Yeni anahtar üretin, yalnız sunucu ortamına koyun, yayınlayın, eski anahtarı iptal edin. Dosyayı son halinden silmek iptal etmez. GitHub secret scanning, depo içeriğindeki bilinen kimlik kalıplarını işaretler. Herkese açık depolarda bu tarama kendiliğinden çalışır. Yedektir. Asıl iş yenilemedir. İyi hali: sağlayıcı eski anahtarı reddeder; yenisi git'te ve istemci paketinde yoktur.

6. İlk kullanıcıdan önce harcama tavanı veya fatura uyarısı açık

Anahtarın faturalandırdığı sağlayıcı hesabını açın. Hesabın sunduğu harcama tavanını veya fatura uyarısını açın. Bildirim, okuduğunuz bir kutuya gelsin. İyi hali: çağrıyı durduran ya da kısmak için konmuş bir sınır vardır; yalnızca sonradan düşen bir fiş değil. Tavan, sızmış anahtarı onarmaz. Yukarıdaki bir kontrol kaçırıldıysa zararın süresini kısaltır.

7. Veri yazan yollar çağıranı doğrular

Veri oluşturan, güncelleyen veya silen işleyicileri dökün: POST, PUT, PATCH, DELETE ve sunucu eylemleri. Oturumu veya token'ı yükleyip yoksa isteği reddeden satırı bulun. İyi hali: kimliği doğrulanmamış çağrı, yazmadan önce durur. Kullanıcı kimliği, istemcinin kendisinin yazabildiği bir alandan değil, oturumdan gelir. Düğmeyi gizlemek kimlik doğrulama değildir.

8. Tarayıcıda service-role veya yönetici anahtarı yok

İstemci kaynağında ve kurulan pakette service-role anahtarı, secret key ve satır kurallarını aşan ya da proje sahibi gibi davranan yönetici token'ı arayın. Herkese açık olması tasarlanmış ve bu kurallarla sınırlı bir publishable veya anon anahtar istemcide kalabilir. Kuralları atlayan anahtar kalamaz. İyi hali: yönetici işi yalnız sunucuda, o anahtar yalnız sunucu ortamında, istemci aramasında eşleşme yok.

9. Kilit dosyası commit'te ve denetimi okudunuz

package-lock.json, pnpm-lock.yaml, yarn.lock veya eşdeğeri git'te olsun. Kurulum o zaman tekrarlanır. Paket yöneticisinin denetim komutunu çalıştırın. Kimlik doğrulama, ödeme veya HTML işleyen paketlerdeki yüksek önemli uyarıları okuyun. İyi hali: kilit dosyası depodadır ve bu yollarda görmezden gelinen kritik bir açık yoktur. Yayın günü her bağımlılığı yükseltmeyin. Bu yollara değenleri düzeltin ya da bilinçli olarak kabul edin.

10. /security-review çalıştı, okundu, yeniden çalıştı

Bu depoda Claude Code'u açın. İletinin başına /security-review yazın. İyi hali: okuduğunuz bir rapor, kabul edip yeniden kontrol ettiğiniz düzeltmeler ve hâlâ doğru olan 1–9. maddeler. Fark boşken gelen temiz sonuç onay değildir. Nedeni bir sonraki bölümde.

/security-review nasıl çalıştırılır

/security-review, Claude Code'un yerleşik komutudur. Komut referansında yer alır. /code-review değildir.

Proje dizininde açılmış oturumda, iletinin başına yazarsınız. Komut, geçerli dalı origin üzerindeki varsayılan dalla karşılaştırır. Enjeksiyon, kimlik doğrulama sorunları ve veri ifşasına bakar. Bu origin uzak adresi şarttır. Taban dal yoksa incelenecek bir fark da yoktur. Komut sayfası ambiguous argument hatasından söz eder ve hata referansına yönlendirir. Uzak adresi düzeltip yeniden çalıştırın.

Komut, çalışma kopyanızdaki kaynağı okur. Canlı siteyi açmaz. Geçen bir tur, çoktan yayındaki paketin temiz olduğunu kanıtlamaz.

Anthropic yardım merkezi aynı komutu, commit öncesi isteğe bağlı kontrol diye anlatır. Bulgular geldikten sonra düzeltmeyi Claude'dan isteyebileceğinizi yazar. Otomatik incelemenin elle bakışın yerine geçmediğini, onu tamamladığını da söyler. Bkz. Automated Security Reviews in Claude Code.

Komut referansı /security-review için --fix bayrağı belgelemez. --fix, başka bir komut olan /code-review içindir. Bayrak uydurmayın. İstediğiniz değişikliği düz cümleyle isteyin. Saklamadan önce değişikliği okuyun.

Sonuçla yapılacaklar:

1. Her bulguyu okuyun. Birini eliyorsanız nedenini yazın.
2. Kabul ettiğiniz düzeltmeyi aynı oturumda Claude'dan isteyin. Değişikliği siz okuyun.
3. /security-review komutunu yeniden çalıştırın.
4. Dalınız origin varsayılan dalıyla aynıysa fark boş kalabilir. Boş sonuç, deponun tamamının tarandığı anlamına gelmez. Güvenlik rehberi, /security-review komutunun geçerli daldaki değişiklikleri kapsadığını ve çalışan hizmeti değil, çalışma kopyasındaki kaynağı okuduğunu söyler. Varsayılan dalda zaten duran bir dosya için Claude'dan o dosyayı incelemesini isteyin. On maddeyi yine uygulayın.

Ayrı bir security-guidance eklentisi, Claude yazarken koda bakıp bulguları aynı oturumda ele alabilir. Bu, resmi eklenti pazarından kurulan başka bir araçtır. /security-review yazmak onu açmaz.

Ekran görüntüsü, eski commit veya yayındaki pakete gömülmüş anahtar için /security-review kapsamında belgelenmiş bir vaat yoktur. Bunlar 2, 3 ve 5. maddelerdedir.

Sık sorulanlar

Güvenlik uzmanı olmak gerekir mi?

Hayır. Buradaki hatalar kendi deponuzda görünür: istemci kodundaki sır, git'in izlediği .env, oturum kontrolü olmayan yazma yolu, paketteki yönetici anahtarı. Bunlar için arama ve git yeter. /security-review, dal farkına bir okuma daha ekler. İkisi de sizi sızma testi yapan biri yapmaz. İkisi de uygulamanın güvenli olduğuna dair belge değildir.

Anahtar zaten depodaysa ne olur?

Yenileyin. Yeni anahtar üretin, yalnız sunucu ortamına koyun, yayınlayın, eskisini iptal edin. Satırı silen commit, eski commit'i geçmişte bırakır. O silmeden önce klonlayan kişide değer durabilir. Ekran görüntüsü ve sohbete yapıştırılmış metin de aynı durumdur. Yenilemeden sonra yeni anahtarın izlenmediğini ve istemci paketinde olmadığını doğrulayın.

/security-review listenin yerine geçer mi?

Hayır. Geçerli dal farkı üzerinde tek geçiştir ve origin ister. Hiç açmadığınız harcama tavanını, paylaştığınız ekran görüntüsünü veya uzun süre önce varsayılan dala inip artık farkta olmayan anahtarı görmez. Bunlar için liste var. Taze değişikliğe bir güvenlik okuması gelsin diye komut var. Sonra çıktıyı okuyun. Okunmamış rapor hiçbir şeyi incelememiş demektir.

Yayına almadan önce

Yayınlayacağınız dalda 1–9. maddeleri gezin. /security-review çalıştırın, yalnız okuduğunuz düzeltmeleri alın, komutu yeniden çalıştırın. Anahtar istemcide, git'te veya bir ekran görüntüsünde kaldıysa yenilemeyi yayından önce yapın.