AI Destekli Geliştirmenin Hız Tuzakları

Hepimiz başımıza geldi: Öğleden sonra Lovable, Bolt veya Cursor'a yüklenip akşam yemeğinde canlı bir URL ile karşısına çıktın. Sanki bir sihirbazlık. Platform hostingi halletti, SSL kendiliğinden geldi, küçük yan projen birden "gerçek" oldu.

Ama gelgelelim bir gerçek var ki üzerine ne kadar düşünürsem düşüneyim: hızlı çıkarmak, güvenli çıkarmak demek değil. Vibe coding devrimini izleyen biri olarak, o öğleden sonra-URL sürecinin geride ne bıraktığını konuşmamız gerektiğini düşünüyorum.

Yakın tarihli bir araştırma, yapımcılarının kamuya açık bir şekilde yayınladığı 155 vibe-coded uygulamayı taradı. Doksan dokuzu hâlâ canlı ve taranabilir durumdaydı. Sonuçlar? Bir o kadar umut verici, bir o kadar endişe verici—ve bu sonuçlar, lansman öncesi kontrol listelerimizi değiştirmeli.

İyi Haber: Sırlar Gizli Kaldı

Beni şaşırtan şey şu: tarama yapılan uygulamaların yalnızca yüzde 1'i gerçek secret key'leri tarayıcıya sızdırdı.

Başkasının bütçesini eriten açıkta kalmış OpenAI API key'leri yok. İstemci tarafı JavaScript'inde süzülen AWS kimlik bilgileri yok. Bir banka hesabını boşaltmaya hazır Stripe live key'leri yok.

Bu bana önemli bir şey söylüyor: Modern AI kodlama platformları varsayılan ayarlarını gerçekten iyileştirmiş. Bolt veya Replit'te yeni bir proje oluşturduğunda, platform seni secret'ları edge function'lara yönlendiriyor, tarayıcı bundle'ına boca etmiyor. Bu gerçekten iyi bir güvenlik UX tasarımı.

Ama yüzde 1 hâlâ yüzde 1'dir. Bir açığa çıkan key, 50.000 dolarlık bir OpenAI faturası, tehlikeye uğramış bir AWS hesabı veya startup'ını daha başlamadan batıran bir Stripe ihtilafı olabilir. O yüzde 1'den biri olma.

Kimsenin Konuşmadığı Supabase Problemi

İşte işlerin gerçekten karıştığı yer.

Canlı vibe-coded uygulamaların yüzde 37'si Supabase anonymous key'ini frontend koduna gömüyor. Ve panik yapmadan önce—bu aslında beklenen bir şey. Supabase tam da böyle tasarlandı. Anon key herkese açık olmalı; veri güvenliğin Row Level Security (RLS) policies'lerinden gelmeli.

İşte problem: RLS opt-in. Tablolar başlangıçta tamamen açık geliyor. Ve gece 11'de, lansman deadline'ına yetişmek için yarışırken, o checkbox'ı kaçırmak inanılmaz kolay.

RLS'si devre dışı kalmış—ya da daha kötüsü, tembel bir using (true) policy'si olan—her tablo, o kamuya açık anon key'e sahip herkes için sonuna kadar açık bir kapı. Bir saldırganın hacklemesine gerek yok. Sadece... veritabanını sorguluyor, çünkü sen bir ayarı unutmuşsun.

Bunu ne kadar vurgulasam az: pasif tarama RLS yanlış yapılandırmalarını tespit edemez. Tarayıcı sadece frontend'i görüyor. Açık, veritabanında. Canlıya çıkmadan önce bunu manuel olarak, tablo tablo kontrol etmelisin.

Aynı tavsiye Firebase için de geçerli (tarama yapılan uygulamaların yüzde 4'ünde görüldü). Security rules opsiyonel eklemeler değil—tüm güvenlik modelinin kendisi.

Görmezden Gelinen Yapılacaklar Listesi: Security Headers

HTTP security header'ları hiç düşünmediysen, yalnız değilsin. Tarama yapılan uygulamaların yüzde 91'inde Content-Security-Policy eksik, yüzde 88'i herhangi bir siteden iframe içine gömülebilir durumda (selam, clickjacking).

Bunlar egzotik açıklıklar değil. Yıllardır en iyi uygulama olan standart sağlamlaştırma adımları. Vibe coding pipeline'ı bunları varsayılan olarak eklemiyor, o kadar.

Tarama sonuçları:

• Yüzde 91 Content-Security-Policy eksik
• Yüzde 88 X-Frame-Options / frame-ancestors eksik
• Yüzde 37 X-Content-Type-Options eksik
• Yüzde 38 Referrer-Policy eksik
• Yüzde 8 Strict-Transport-Security eksik
• Yalnızca yüzde 5 tüm security header'ları yapılandırmış

Parlak nokta? Hosting platformları HSTS'yi otomatik hallediyor, o kısım büyük ölçüde kaplı. Ama CSP açığı ciddi. AI'ın yazdığı bir bileşen kullanıcı tarafından oluşturulan içerik render ettiğinde veya üçüncü taraf script'ler entegre ettiğinde, CSP son savunma hattın. Bir tane yoksa, XSS saldırıları saklanacak yer aramak zorunda kalmaz.

Lansman Cilası Bozukluğu

Beklemediğim ama tamamen ilgimi çeken bir bulgu: Vibe-coded uygulamaların yüzde 30'u Open Graph tag'leri olmadan yayınlanıyor.

Bu, birisi ürününü X (Twitter), Discord veya LinkedIn'de paylaştığında, önizleme görseli, başlık veya açıklama olmadan çıplak bir URL olarak görünmesi demek. Sadece... metin. 2024'te bu profesyonellikten uzak duruyor ve tıklama oranlarını öldürüyor.

Tarama bulgularındaki diğer lansman günü eksiklikleri:

• Yüzde 11 meta description yok
• Yüzde 77 sitemap.xml yok
• Genel güvenlik notu ortalaması B eksi (84/100), yalnızca yüzde 13 A ile bitirmiş

Uygulamalar felaket değildi—sadece cilaya ihtiyaçları vardı. Seni lansmana götüren hız, <meta property="og:title">'ı unutturan hızın ta kendisi.

Beş Dakikalık Lansman Öncesi Kontrol Listem

Bu araştırmayı okuduktan sonra kişisel kontrol listemi güncelledim. İşte o Show HN thread'ini paylaşmadan önce gerçekten önemli olan şeyler:

1. Bundle'ında sırları avla Build çıktında sk-, sk_live_, service_role, ghp_ ara. Eşleşen her şey derhal değiştirilmeli ve bir edge function ya da environment variable'a taşınmalı. Bir açığa çıkan key yeterli.

2. Her Supabase veya Firebase tablosunu denetle Dashboard'u aç. Her kamuya açık tablo RLS etkin olmalı. Her policy spesifik olmalı—asla using (true) yok. Bir yanlış yapılandırılmış tablodaki okuma erişimi, tüm kullanıcı veritabanını açığa çıkarabilir.

3. Şu security header'ları ekle

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Test etmek istiyorsan Content-Security-Policy-Report-Only ile başla, uygulama olmadan. Ama mutlaka deploy et.

4. Production source map'lerini kapat *.map dosyaların senin için debug altını, saldırganlar için altın madeni. Çoğu platformda bir toggle var. Lansmandan önce kapat.

5. Open Graph metadata'larını ekle En azından: og:title, og:description, og:image. Lansman postun bir timeline'da iyi görünmeyi hak ediyor.

6. sitemap.xml oluştur Gelecekteki SEO'cu benlik sağ olacak. Çoğu platform bunu otomatik oluşturuyor—seninkinin oluşturup oluşturmadığına bak.

Büyük Resim

Şöyle düşünüyorum: Vibe coding sorun değil. Sorun, "benim makinemde çalışıyor" ile "production'a hazır" arasındaki boşluk. Geleneksel geliştiriciler bu boşluğu yıllar süren acı dolu deployment'larla öğrendi. Vibe coder'lar bunu daha hızlı öğreniyor—bu aslında iyi bir şey.

Platformlar iyileşiyor. Varsayılanlar daha iyi hale geliyor. Ama güvenlik sağlamlaştırması SSL sertifikaları kadar otomatik olana kadar, sorumluluk biz yapımcılara düşüyor—lansmandan önce o beş dakikalık kontrol listesini eklemek bizim işimiz.

Vibe coding'in hızı bir süper güç. Güvenlik, bunu kullanmanın bedeli olmak zorunda değil.

Lansman öncesi güvenlik rutinin ne? Yorumlarda kontrol listesi eklemelerini paylaş—her zaman geliştirmek istiyorum.