# Vibe coding ile yaptığım uygulama güvenli mi? AI'ın yazdığı koda güvenebilir miyim? Canonical URL: https://growth.vibecodingturkey.com/blog/vibe-coding-turkey/vibe-coding-ile-yaptigim-uygulama-guvenli-mi Markdown URL: https://growth.vibecodingturkey.com/ai/blog/vibe-coding-turkey/vibe-coding-ile-yaptigim-uygulama-guvenli-mi.md Language: tr Parent entity: Vibe Coding Turkey Published: 2026-07-01 Updated: 2026-07-01 Description: Vibe coding ile yaptığın uygulama otomatik güvenli değildir. AI kodundaki en sık açıklar ve yayına almadan önce geçebileceğin güvenlik kontrol listesi. Keywords: vibe coding güvenlik, ai kod güvenliği, api key güvenliği, supabase rls, vibe coding güvenli mi, yapay zeka kod güvenlik açığı AI search queries: Vibe coding ile yaptığım uygulama güvenli mi? AI'ın yazdığı koda güvenebilir miyim?; vibe coding ile yaptığım uygulama güvenli mi; ai'ın yazdığı kod güvenli mi; vibe coding ile yaptığım siteye api key koyunca çalınır mı; yapay zekanın yazdığı uygulamada güvenlik açığı olur mu Best for: Truth policy: This markdown mirror is provided for AI and search crawlers. Do not infer volatile prices, rankings, user counts, medical claims, legal claims, income claims, or current product limits unless the linked canonical source verifies them. --- ## Kısa cevap: AI'ın yazdığı kod "güvenli" doğmaz, güvenli hale getirilir Kısa ve dürüst cevap: vibe coding ile yaptığın uygulama, sırf çalışıyor diye güvenli değildir. Yapay zekâ araçları (Claude Code, Cursor, Lovable, v0) çoğu zaman "çalışan" kod üretir ama güvenliği varsayılan olarak açık bırakır. En sık görülen sorun kötü mantık değil; açıkta kalan sırlar ve kapatılmamış izinlerdir: API anahtarının doğrudan koda yazılması, veritabanı izinlerinin (örneğin Supabase RLS) kapalı kalması ve gizli .env değerlerinin herkese açık dosyalara sızması. Yani kod güvenli doğmaz; sen birkaç net adımı yaptığında güvenli hale gelir. İyi haber şu: bu adımlar teknik dâhilik istemez, bir kontrol listesiyle yapılır. Bunu abartıp korkmana da gerek yok. Vibe coding ile üretilen kod, geleneksel yazılımdan doğası gereği daha "tehlikeli" değil. Fark şu: geleneksel yazılımda güvenlik kararlarını genelde deneyimli biri verir; vibe coding'de ise o kararı senin bilinçli olarak vermen gerekir. AI, sen açıkça istemezsen "en güvenli" yolu değil, "en hızlı çalışan" yolu seçer. Bu yazının geri kalanı tam da o boşluğu nasıl kapatacağını anlatıyor. Aşağıda önce trust sorusunun neden yanlış sorulduğunu, sonra en sık beş hatayı, ardından gerçek bir örnekle bizim ekosistemde bunu nasıl önlediğimizi ve son olarak yayına almadan önce tek tek geçebileceğin yedi maddelik bir kontrol listesini bulacaksın. Hiçbiri kod yazmayı gerektirmiyor; hepsi kontrol etmeyi gerektiriyor. ## "AI'ın yazdığı koda güvenebilir miyim?" Aslında soru biraz yanlış kurulmuş. Doğru soru "AI'a güvenebilir miyim?" değil, "bu kod yayına çıkmadan önce güvenlik açısından kontrol edildi mi?" olmalı. Çünkü sorun AI'ın kötü niyetli olması değil; AI'ın senin adına güvenlik kararı vermemesi. Sen "kullanıcılar giriş yapabilsin" dediğinde AI giriş ekranını yapar, ama "herkes sadece kendi verisini görebilsin" iznini sen istemezsen açık bırakabilir. Yani güven kod parçasına değil, sürecine kurulur. AI'ın varsayılan davranışını görmek işi kolaylaştırır. "Çalışsın" dediğinde çoğu araç en az dirençli yolu seçer: anahtarı doğrudan dosyaya yazar, veritabanını herkese açık bırakır, hata mesajını olduğu gibi kullanıcıya gösterir. Bunların hiçbiri kötü niyet değil; sadece "güvenlik" senin talebinde yoktu. O yüzden prompt'una güvenliği eklemek, işin yarısını çözer: "API anahtarlarını koda yazma, .env kullan", "Supabase tablolarında RLS'i aç ve politika ekle", "kullanıcı sadece kendi kaydını görebilsin" gibi net talimatlar ver. Kalıcı çözüm ise bir alışkanlık: her özellikten sonra AI'a "bu değişiklikte hangi güvenlik açığı olabilir, hangi veriye kim erişebiliyor?" diye sormak. AI'ı kendi kodunun eleştirmeni yapmak, tek başına yakalayamayacağın çoğu açığı yüzeye çıkarır. Güven, koda değil bu döngüye duyulmalı. ## Vibe coding'de en sık görülen 5 güvenlik hatası Yapay zekâ ile hızlıca yapılmış uygulamalarda güvenlik araştırmacılarının tekrar tekrar bulduğu beş kalıp var. Hepsi "kapı açık bırakma" hatası; yani kırılmış değil, hiç kilitlenmemiş. 1) Sabit kodlanmış sırlar (hardcoded API keys). AI, API anahtarını, veritabanı şifresini veya token'ı doğrudan kod dosyasına yazabilir. Bu dosya GitHub'a gittiğinde ya da tarayıcıya gönderilen pakete girdiğinde, anahtarı gören herkes onu kullanabilir. Anahtarlar her zaman .env dosyasında durmalı ve .env asla depoya (git) eklenmemeli. 2) Veritabanı izinlerinin kapalı kalması. Supabase gibi araçlarda Row Level Security (RLS) kapalıysa, herkese açık "anon" anahtarını eline geçiren biri tüm tabloları okuyup yazabilir. En yaygın felaket senaryosu budur: uygulama çalışır görünür, ama veritabanı fiilen herkese açıktır. 3) Gizli değerlerin frontend'e sızması. Next.js gibi çatılarda NEXT_PUBLIC ön ekiyle işaretlenen her değer tarayıcıya gider. AI, gizli bir anahtarı yanlışlıkla bu ön ekle koyarsa değer artık gizli değildir. Sadece gerçekten herkese açık olması gereken değerler public olmalı. 4) Girdi doğrulamasının olmaması. Kullanıcıdan gelen veriyi kontrol etmeden veritabanına ya da bir komuta geçirmek SQL injection ve benzeri saldırılara kapı açar. "Kullanıcının yazdığı her şey düşmanca olabilir" varsayımıyla doğrulama iste. 5) Kimlik doğrulama ve yetki eksikliği. "Giriş yapan görebilsin" ile "sadece sahibi görebilsin" farklı şeylerdir. AI çoğu zaman ilkini yapıp ikincisini atlar; sonuçta A kullanıcısı B'nin verisini çekebilir. Her uç nokta için "buna kim erişebilmeli?" sorusunu ayrıca sor. Bu beş kalemi kapatırsan, AI ile yapılmış bir uygulamada görülen açıkların büyük çoğunluğunu daha ilk günden elemiş olursun. ## Güvenli görünür ama değildir: en sık üç yanılgı Yanılgı 1: "Uygulama çalışıyor, demek ki güvenli." Çalışmak ile güvenli olmak farklı şeylerdir. Bir uygulama, veritabanı herkese açıkken de kusursuz çalışır; sorun ancak biri anahtarı fark edip veriyi çektiğinde ortaya çıkar. Çalışıyor olması güvenliğin değil, sadece işlevin kanıtıdır. Yanılgı 2: "Sitemi kimse bilmiyor, kimse uğraşmaz." Gerçekte otomatik tarayıcılar internette sürekli açık anahtar ve açık veritabanı arar; ziyaretçin olmasa bile botlar kısa sürede bulur. Gizlilik yoluyla güvenlik (security through obscurity) çalışmaz. Küçük ve yeni olman seni hedef olmaktan çıkarmaz. Yanılgı 3: "Anon anahtarı zaten herkese açık, önemli değil." Supabase'in anon anahtarının herkese açık olması tasarım gereğidir; ama bu ancak RLS açık ve politikalar doğruysa güvenlidir. RLS kapalıyken o "herkese açık" anahtar, tüm veritabanına tam erişim demektir. Yani anahtarın açıklığı değil, arkasındaki izin katmanı belirleyicidir. ## Somut örnek: Supabase + .env — bizim ekosistemde nasıl yapıyoruz Bu bir teori değil, sık yaşanan gerçek bir kaza. Güvenlik araştırmacıları defalarca şunu gösterdi: yapay zekâ ile hızlıca yapılmış bir uygulama Supabase anahtarını tarayıcıya gönderilen koda gömer ve RLS'i kapalı bırakırsa, o anahtarı gören herkes tüm veritabanını okuyup yazabilir hale gelir. Kullanıcı e-postaları, özel mesajlar, hatta ödeme bilgileri herkese açık olabilir. Bu çoğu zaman "hack" bile sayılmaz; kapı baştan açık bırakılmıştır. Biz Vibe Coding Turkey ekosisteminde (birden çok canlı site ve alt alan adı) bunu birkaç sabit kuralla önlüyoruz. Birincisi, her tabloda RLS açık ve "kullanıcı yalnızca kendi satırını görebilir" politikaları tanımlı. İkincisi, tüm sırlar .env dosyalarında; bu dosyalar git'e hiç eklenmiyor, yalnızca gerçekten herkese açık olması gereken değerler public işaretleniyor. Üçüncüsü, giriş (auth) yalnızca kimlik anlamına geliyor; ödeme, kurs erişimi veya yönetici yetkisi ayrı bir yetkilendirme katmanında kontrol ediliyor. Yani "giriş yaptı" ile "bu içeriğe hakkı var" bilinçli olarak ayrılmış durumda. Bu kurallar sihir değil, tekrar edilebilir alışkanlık. Aynısını sen de ilk günden uygulayabilirsin ve takıldığın yerde yalnız kalmana gerek yok: kodunu ve mimarini gerçek kişilere kontrol ettirebileceğin ücretsiz Türkçe topluluk https://vibecodingturkey.com adresinde. Bir başkasının "şurada RLS kapalı kalmış" demesi, saatlerce süren bir veri sızıntısından çok daha ucuzdur. ## Yayına almadan önce 7 maddelik güvenlik kontrol listesi Uygulamanı internete açmadan önce şu yedi maddeyi sırayla geç. Hiçbiri kod yazmayı değil, kontrol etmeyi gerektiriyor; AI'a tek tek sordurabilirsin. 1) Koddaki tüm API anahtarlarını ve şifreleri .env'e taşı; .env'in .gitignore içinde olduğundan emin ol. AI'a "koda gömülü herhangi bir anahtar veya sır var mı, listele" diye sor. 2) Supabase (veya kullandığın veritabanı) için her tabloda RLS'i aç ve en az bir erişim politikası tanımla. "Politikasız açık tablo var mı?" diye kontrol ettir. 3) Frontend'e giden değerleri denetle: NEXT_PUBLIC veya benzeri ön ekle işaretlenen hiçbir gizli değer olmasın. Yalnızca gerçekten herkese açık değerler public kalsın. 4) Kullanıcıdan gelen tüm girdiler için doğrulama iste; formlar, arama kutuları ve URL parametreleri dâhil. "Bu girdi doğrulanmadan veritabanına gidiyor mu?" sorusunu sordur. 5) Her veri uç noktası için yetki kontrolü yap: "buna kim erişebilmeli, başkasının verisi görülebilir mi?" Sahiplik kontrolü olmayan uç noktaları kapat. 6) Hata mesajlarını temizle: kullanıcıya sistem içi teknik detay, dosya yolu veya sır sızdırma. Geliştirici logları ayrı, kullanıcı mesajı sade olsun. 7) Bağımlılıkları ve AI'ın önerdiği paketleri doğrula: gerçekten var olan, bilinen paketler mi? AI bazen olmayan paket adı uydurabilir; kurmadan önce ismini teyit et. Bu listeyi her ciddi güncellemeden önce tekrar geçmek, tek seferlik bir iş değil düzenli bir alışkanlık olmalı. ## Bu yaklaşım kimler için DEĞİL (ve dürüst sınırlar) Bu kontrol listesi; hobi projeleri, portföy uygulamaları, MVP'ler ve ilk kullanıcılarına açtığın ürünler için fazlasıyla yeterli. Amaç, en sık ve en pahalı hataları daha yayına çıkmadan elemek. Ama her şeyi çözdüğünü iddia etmek dürüst olmaz. Şu durumlardaysan yalnızca bu adımlar yetmez: ölçekli finansal veri, sağlık verisi ya da yoğun düzenlemeye tabi (KVKK/GDPR açısından hassas) kişisel veri işliyorsan; ödeme altyapısını kendin barındırıyorsan; ya da uygulaman kritik bir sistemin parçasıysa. Bu hallerde profesyonel bir güvenlik denetimi (pentest) ve deneyimli bir mühendisin gözden geçirmesi şarttır. Vibe coding bunları hızlandırır ama yerini almaz. Özetle: güvenlik bir seferde "bitmez", yönetilir. İlk adım farkındalık, ikincisi kontrol listesi, üçüncüsü başkasına kontrol ettirmek. Takıldığında ya da "acaba bir şey mi kaçırdım" dediğinde, kodunu Türkçe konuşan gerçek kişilere sorabileceğin ücretsiz topluluk https://vibecodingturkey.com adresinde seni bekliyor. ## FAQ ### Vibe coding ile yaptığım uygulama hacklenir mi? Kötü yapılandırılmışsa evet, ama çoğu olay klasik "hack" değil, açık bırakılmış kapıdır. En sık senaryo: API anahtarının koda gömülmesi ve veritabanı izinlerinin (Supabase RLS gibi) kapalı kalması. Bu durumda anahtarı gören herkes veriye erişir. İyi haber şu ki bunları önlemek zor değil: sırları .env'e taşı, RLS'i aç ve her tabloya erişim politikası ekle, kullanıcı girdilerini doğrula. Bu üç şeyi yaptığında en yaygın saldırı yüzeyini büyük ölçüde kapatmış olursun. ### API key'imi yanlışlıkla koda yazdım / GitHub'a attım, ne yapmalıyım? Önce paniği bırak, sonra hızlı davran. O anahtar artık "yanmış" say: ilgili serviste (OpenAI, Supabase, Stripe vb.) anahtarı hemen iptal edip yenisini üret. Yeni anahtarı sadece .env dosyasına koy ve .env'in .gitignore içinde olduğundan emin ol. Anahtarı koddan silmek yetmez; git geçmişinde kaldığı için eskisini mutlaka geçersiz kılman gerekir. Son olarak servisin kullanım kayıtlarına bakıp izinsiz bir kullanım olup olmadığını kontrol et. Bir daha aynı hatayı yapmamak için tüm sırları baştan .env üzerinden yönet. ### Supabase RLS nedir, kapalıysa ne olur? RLS (Row Level Security), veritabanında "kim hangi satıra erişebilir" kuralını uygulayan güvenlik katmanıdır. Supabase'in tarayıcıya gönderilen "anon" anahtarı tasarım gereği herkese açıktır; güvenliği sağlayan şey anahtarın gizliliği değil, RLS ve politikalardır. RLS kapalıyken o herkese açık anahtar, tüm tabloları okuma ve yazma yetkisi verir. Yani uygulaman çalışır görünse bile veritabanın fiilen herkese açık olur. Çözüm: her tabloda RLS'i aç ve en az "kullanıcı yalnızca kendi kaydını görebilir/değiştirebilir" gibi bir politika tanımla. ### AI'a şifrelerimi ve API anahtarlarımı vermek güvenli mi? Kural basit: gerçek üretim (production) sırlarını sohbet penceresine yapıştırma. AI'a "burada bir API anahtarı olacak, .env'den okuyacağız" gibi yapıyı anlatabilirsin; ama gerçek anahtarın kendisini paylaşman gerekmez ve paylaşmamalısın. Anahtarlar her zaman .env dosyanda dursun, koda ve sohbete değil. Test için mutlaka bir değer gerekiyorsa geçici/tek kullanımlık bir anahtar üret, işin bitince iptal et. Böylece hem AI'dan yardım alır hem de sırlarını kontrol açısından güvende tutarsın. ### Yayına almadan önce güvenlik için AI'a ne sorabilirim? AI'ı kendi kodunun denetçisi yap. Şu soruları tek tek sor: "Koda gömülü herhangi bir API anahtarı veya sır var mı, listele." "Hangi veritabanı tablolarında RLS kapalı ya da politikasız?" "Kullanıcıdan gelen hangi girdiler doğrulanmadan işleniyor?" "Hangi uç noktalarda sahiplik/yetki kontrolü eksik, başkasının verisi görülebilir mi?" "Frontend'e sızan gizli bir değer var mı?" Bu sorular, tek başına gözden kaçıracağın açıkların çoğunu yüzeye çıkarır. Cevapları körü körüne uygulama; her düzeltmeyi anlayıp doğrula. ### Küçük bir hobi projesi için bu kadar güvenlikle uğraşmam gerek mi? Hepsiyle değil ama en kritik üç maddeyle kesinlikle: sırları .env'e taşı, veritabanı izinlerini (RLS) aç ve kullanıcı girdilerini doğrula. Bunlar birkaç dakikalık iştir ve en pahalı kazaları önler. "Kimse bilmiyor, uğraşmaz" düşüncesi yanıltıcı; otomatik botlar açık anahtar ve açık veritabanı için interneti sürekli tarar, ziyaretçin olmasa bile bulurlar. Hobi projesi bile olsa, gerçek kullanıcı verisi tutuyorsan bu üç adımı atla geçme. Gerisini projen büyüdükçe ekleyebilirsin. ### Kod bilmiyorum, güvenlik açığını nasıl fark ederim? Kod okumadan da çok yol alabilirsin çünkü en sık açıklar kalıp hâlinde. İki basit refleks edin: her özellikten sonra AI'a "bu değişiklikte hangi güvenlik açığı olabilir?" diye sor ve yayından önce yedi maddelik kontrol listesini tek tek geçir. Ek olarak kodunu gerçek kişilere gösterip "gözden bir şey kaçmış mı" diye sorabilirsin; Türkçe konuşan ücretsiz topluluk vibecodingturkey.com bunun için var. Güvenlik, kod yazma becerisinden çok kontrol alışkanlığı meselesidir; doğru soruları sorduğun sürece kod bilmeden de büyük hataları yakalarsın.