Vibe coding uygulamaları güvenli mi? Kontrol edilecek 8 açık

Vibe coding ile yapılan uygulamalar güvenli mi?

Varsayılan olarak değil: burada anılan büyük çalışmaların hepsi, incelediği uygulamaların büyük bir bölümünde ciddi güvenlik açıkları buldu ^[3][4][5]. Uygulamalar genellikle çalışıyor. Sorun, yabancılara neye izin verdikleri.

2026'da yapılan bir denetim, Claude Code ve Lovable ile yapılmış 9.041 açık kaynak uygulamayı topladı ve bunlardan herkese açık yayındaki 200'ünü inceledi. Toplam 1.186 açık buldu; 200 uygulamanın 182'sinde (%91,0) en az bir açık vardı ^[4]. Bu açıkların %65,77'si kritik veya yüksek olarak derecelendirildi; %18,47'si kritikti ^[4].

Yazarlar daha iyi promptların ve ajan ayarlarının sorunu çözüp çözmediğini de test etti. Sorunu azalttılar ama ortadan kaldıramadılar; aynı görev üç kez çalıştırıldığında bir seferinde güvenli, bir sonrakinde güvensiz sonuç verebiliyordu ^[4]. Yani bir sürümdeki temiz sonuç, bir sonraki hakkında pek bir şey söylemiyor.

Yöntemin temelleri için Pouyam rehberi Vibe Coding Explained: What It Is, How It Works and the Real Risks'e bakın. İlk proje için Vibe Coding for Beginners: How to Start Safely in 2026 bir başlangıç planı sunar. Bu sayfa bir seviye daha derine iniyor: belirli açıklar ve her birinin nasıl test edileceği.

Güvenlik çalışmaları vibe coding uygulamalarında ne buluyor?

Dört bağımsız kaynak aynı zayıf noktayı gösteriyor: yanlış kişinin okuyabildiği veya değiştirebildiği veriler ^[1][3][4][5].

• Yayındaki 200 uygulamanın denetimi (2026): Bozuk erişim kontrolü, 1.186 açığın 339'uyla (%28,58) en büyük kategoriydi ve uygulamaların %64,00'ını etkiledi. Enjeksiyon %54,00'ını, kimlik doğrulama hataları %51,50'sini etkiledi ^[4].
• ACM CCS 2026 çalışması: Tam geçmişi olan 8.641 Lovable deposunda okuma kurallarının %11,2'si oturum açmamış ziyaretçilere açıktı ve depoların %61,2'sinde en az bir böyle kural vardı. Yeniden oynatma testi, örneklenen 400 deponun 353'ünde ifşayı doğruladı ^[5].
• Escape (Ekim 2025): Lovable, Base44 ve Create.xyz gibi platformlarda yapılmış 5.600'den fazla herkese açık uygulamanın pasif taraması 2.000'den fazla açık, 400'den fazla ifşa olmuş gizli bilgi ve tıbbi kayıtlar, IBAN'lar (banka hesap tanımlayıcıları), telefon numaraları ve e-postalar dahil 175 kişisel veri vakası buldu ^[3].
• CVE-2025-48757 (2025): 21 Mart 2025'te tamamlanan bir tarama, 1.645 Lovable projesinin 170'inde, yaklaşık %10,3'ünde, yetersiz satır kurallarına sahip 303 veritabanı uç noktası buldu ^[1].

Escape, taramanın yıkıcı hiçbir işlem yapmadığını, bu yüzden rakamların alt sınır olduğunu vurguluyor; daha derin bir test daha fazlasını bulurdu ^[3]. Aynı ihtiyat buradaki tüm rakamlar için geçerli: Bu çalışmalar dışarıdan görebildiklerini sayıyor.

Yapay zekâ araçları neden güvensiz uygulamalar üretiyor?

Çünkü araçlar çalışan bir uygulama hedefliyor ve güvenlik kuralları, promptta nadiren belirtilen iş ayrıntılarına bağlı ^[4][11].

Çalışan kodu kontrol etmek kolaydır: Sayfa yüklenir, düğme çalışır. Her kaydı kimin görebileceği ise bir iş kararıdır ve kimse bunu yazmazsa araç tahmin etmek zorunda kalır. 2026 denetimi açıkları, yapay zekâ ajanlarının üç sınırı altında toplanan sekiz tekrarlayan hata kalıbına bağlıyor: bellek, hedefler ve bilgi ^[4].

Yapay zekâ modellerine yönelik geniş testler de aynı boşluğu gösteriyor. Veracode'un GenAI Code Security Report 2026 raporu, testlerinde kod üretme görevlerinin yaklaşık %44'ünün bir güvenlik açığı getirdiğini buldu ^[11]. AWS'nin aktardığı bir kıyaslama testinde 12 ajan ayarının en iyisi görevlerin %57'sini doğru çözdü, ancak yalnızca %11,8'ini hem doğru hem güvenli şekilde çözdü ^[10].

Birçok vibe coding uygulaması ayrıca güvenliği veritabanına taşıyor. Tarayıcı doğrudan barındırılan bir veritabanıyla konuşuyor; bu yüzden veritabanı kuralları bir ziyaretçiyle her satır arasındaki tek engel ^[1][6]. Kurallar yoksa veya çok genişse, adresi bilen herkes her şeyi isteyebilir.

Önce hangi 8 güvenlik açığını kontrol etmeliyim?

Çalışmaların en sık bulduğu açıklarla, verebilecekleri zarara göre sıralayarak başlayın ^[1][3][4][5].

1. Açık veritabanı kuralları: Row level security olmayan ya da her ziyaretçinin tüm satırları okumasına izin veren kurallara sahip tablolar. CVE-2025-48757'nin ve ACM bulgularının kökü buydu ^[1][5].
2. Bozuk erişim kontrolü: Oturum açmış bir kullanıcı, adresteki veya istekteki bir kimliği değiştirerek başka birinin kaydını açabiliyor. 2026 denetiminin en büyük kategorisiydi ^[4].
3. Tarayıcıdaki gizli anahtarlar: Ön yüz koduna konmuş bir Supabase secret veya service_role anahtarı, ödeme anahtarı ya da yapay zekâ sağlayıcısı anahtarı. Escape 400'den fazla ifşa olmuş gizli bilgi buldu ^[3][6].
4. Eksik veya zayıf oturum kontrolleri: Oturum olmadan yanıt veren özel sayfalar veya API rotaları. Kimlik doğrulama hataları denetlenen uygulamaların %51,50'sini etkiledi ^[4].
5. Enjeksiyon: Kullanıcı girdisinin kontrolsüz şekilde sorgulara veya HTML'e ulaşması; denetlenen uygulamaların %54,00'ında bulundu ^[4].
6. Yazılabilir tablolar: Ziyaretçilerin yalnızca okumasına değil, veri eklemesine veya değiştirmesine izin veren kurallar. CVE vakasında oturum belirteci olmayan bir istek, "ödendi" olarak işaretli bir kayıt ekledi ve ödeme adımını atladı ^[1].
7. Fazla veri döndüren yanıtlar: Sayfa yalnızca bir isme ihtiyaç duyarken tüm kullanıcı kayıtlarını, e-postaları veya belirteçleri döndüren API'ler. Escape 175 ifşa olmuş kişisel veri vakası saydı ^[3].
8. Riskli ajan erişimi: Üretim kimlik bilgilerine sahip bir kodlama ajanı gerçek zarar verebilir; Temmuz 2025'te bir ajan, kod dondurma sırasında canlı bir veritabanını sildi ^[10].

1-4 arasındaki açıklar, dışarıdan saldıranların istismar ettiklerinin çoğunu kapsar; önce bunları test edin.

Vibe coding uygulamamı bu açıklara karşı nasıl test ederim?

Uygulamayı bir saldırgan gibi kullanın: yabancı olarak, ikinci kullanıcı olarak ve tarayıcının aldığını okuyarak ^[1][4][5]. Bu adımların hiçbiri özel araç gerektirmez.

1. İki test hesabı oluşturun. A hesabıyla bir kayıt oluşturun, adresini veya kimliğini kopyalayın, B hesabıyla giriş yapın ve kaydı açmayı, düzenlemeyi ve silmeyi deneyin. İşe yararsa erişim kontrolü bozuktur ^[4].
2. Oturumu kapatıp tekrarlayın. Aynı adresleri oturumsuz bir gizli pencerede açın. CVE vakasında oturum başlığını kaldırmak tüm kontrolleri atlatmaya yetti ^[1].
3. Ağ sekmesini izleyin. Tarayıcının geliştirici araçlarında sayfanın yaptığı her isteğe ve dönen yanıta bakın. Yanıtlar yalnızca o ekranın ihtiyacını içermeli, asla başka kullanıcıların e-postalarını veya belirteçlerini değil ^[3].
4. Sayfa kodunda anahtar arayın. sb_secret_ ile başlayan dizeleri, service_role etiketini veya ödeme ya da yapay zekâ gibi sağlayıcı anahtarlarını arayın. Publishable anahtar beklenen bir şeydir; secret anahtar ise acil durumdur ^[6].
5. Her tablonun kurallarını kontrol edin. Veritabanı panelinde her tabloda row level security'nin açık olduğunu doğrulayın ve her kuralı basitçe okuyun: kim okuyabilir, kim yazabilir ^[7].
6. Hatalı girdiler deneyin. Her forma çok uzun metinler, tırnak işaretleri ve HTML etiketleri yapıştırın; uygulamanın çöküp çökmediğine veya bunları kod olarak gösterip göstermediğine bakın ^[4].

Yalnızca size ait olan veya test etme izniniz bulunan uygulamaları test edin. Başkalarının uygulamalarını yazılı izin olmadan yoklamayın.

Açık Supabase kurallarını ve sızan anahtarları nasıl düzeltirim?

Her tabloda row level security'yi açın, dar kurallar yazın, gizli anahtarları sunucuda tutun ve sızan her anahtarı değiştirin ^[6][7][8].

• Row level security'yi her yerde açın. Supabase'in rehberi, dışarıya açık bir şemadaki her tabloda bunu açmanızı söylüyor ^[7]. Açıldıktan sonra, siz kural ekleyene kadar herkese açık anahtar hiçbir şeye erişemez ^[7].
• Varsayılan yetkileri kaldırın. Bunları hâlâ varsayılan olarak veren projelerde yeni bir herkese açık tablo, oturum açmamış (anon) ve oturum açmış (authenticated) rollere verilmiş tüm yetkilerle başlar ve kural eklemek bu yetkileri geri almaz ^[7]. Bunları geri alın ve her role yalnızca ihtiyacı olanı verin ^[7].
• Kullanıcı bazlı kurallar yazın. Özel bir tablonun kuralı, oturum açan herkese izin vermek yerine oturum açmış kullanıcının kimliğiyle eşleşmeli. Hassas tablolarda her zaman doğru olan kurallardan kaçının ^[2].
• Gizli anahtarları sunucu tarafında tutun. Supabase'in publishable anahtarı tarayıcıda yalnızca satır kuralları onu sınırladığı için güvenlidir; secret ve service_role anahtarları tüm kuralları atlar ve sunucu kodunda veya güvenli ortam ayarlarında kalmalıdır ^[6].
• Sızan anahtarları yenileyin. Gizli bir anahtar bir kez bile tarayıcıya veya herkese açık bir kod deposuna ulaştıysa yenisini oluşturun ve sızan anahtarı devre dışı bırakın; Supabase'in anahtar rehberi de bunu öneriyor ^[6].

15 Kasım 2026 itibarıyla Supabase'in belgeleri, eski anon ve service_role anahtarlarını 2026 sonuna kadar publishable ve secret anahtarlar lehine kullanımdan kaldırdığını söylüyor ^[8]. Yeni secret anahtarlar tarayıcıda kullanıldığında hata (HTTP 401) döndürüyor, ancak sızan bir anahtar yine de başka araçlardan kullanılabilir ^[6][8]. Şimdi geçiş yapmak, bir uygulamanın kullandığı her anahtarı gözden geçirmek için iyi bir an.

Yerleşik güvenlik tarayıcıları her şeyi yakalar mı?

Hayır: Platform tarayıcıları yardımcı olur, ancak birkaç çalışma en önemli kuralları kaçırdıklarını gösteriyor ^[1][2][5].

2025'te CVE-2025-48757'nin arkasındaki araştırmacılar, Lovable'ın tarayıcısının yalnızca bir satır kuralı olup olmadığını kontrol ettiğini, doğru olup olmadığını kontrol etmediğini tespit etti ^[1]. Uyarılarında ayrıca Lovable'ın yayın kontrolünün kuralsız tabloları işaretlediği, ancak kuralların yeterince sıkı olup olmadığını göstermediği belirtiliyor ^[2]. Açık bir kural böyle bir kontrolden geçer.

ACM çalışması bunu rakamlarla gösteriyor: Altı araçta %6,3 gibi mütevazı bir açık kural oranı bile depoların %56,9'unu en az bir açık tabloyla bıraktı, çünkü tek bir açık kural yeterli ^[5]. Yazarlar, bu tür kuralları commit öncesinde işaretleyen ücretsiz bir denetleyici yayımladı ^[5].

Tarayıcıları ilk filtre olarak kullanın, ardından iki hesaplı ve oturumsuz testleri kendiniz yapın. Aşağıdaki tablo rakamları özetliyor.

Başkalarının vibe coding ile yaptığı uygulamaları kullanmak güvenli mi?

Kişisel, sağlık veya ödeme verisi isteyen her şeye karşı dikkatli olun, çünkü kullanıcılar bir uygulamanın bunları nasıl koruduğunu göremez ^[3][4]. Escape, ifşa olan veriler arasında tıbbi kayıtlar ve IBAN'lar (banka hesap tanımlayıcıları) buldu ^[3].

Bazı basit alışkanlıklar riski azaltır. Her yeni uygulama için ayrı bir şifre kullanın ki bir sızıntı diğer hesapları açmasın; Pouyam rehberi Password Managers Explained: How They Work and Whether They Are Safe bunun nasıl yapılacağını anlatıyor. Uygulamaya yalnızca gereken verileri verin ve uygulama içindeki formlar yerine bilinen ödeme sağlayıcılarının ödeme sayfalarını tercih edin.

Asıl sorumluluk geliştiricilerde. Başkalarının verilerini saklayan bir uygulama yayımlıyorsanız yukarıdaki kontrolleri yayından önce ve her büyük değişiklikten sonra yapın; çünkü tek bir yeni özellik kapatılmış bir açığı yeniden açabilir ^[4][5].