Vibe coding'de güvenlik: yayına almadan önce 19 kontrol.

Şubat 2025'te Andrej Karpathy "vibe coding" diye bir şeyden bahsetti: koda bakmadan, yapay zekâya ne istediğini anlatıp çıkan sonucu kabul ederek yazılım üretmek. Bir yıl içinde bu, hafta sonu projelerinin değil, gerçek kullanıcısı olan ürünlerin geliştirme biçimine dönüştü.

Sorun şu: yapay zekâ çalışan kodu çok iyi yazıyor. Giriş ekranı açılıyor, form kaydediyor, ödeme sayfası yükleniyor. Ama "çalışıyor" ile "güvenli" arasındaki mesafe, demo ile canlı ürün arasındaki mesafe kadar büyük. Ve bu mesafeyi kimse prompt'a yazmadığı için model de kapatmıyor.

Bu yazıda, bir uygulamayı yayına almadan önce kontrol ettiğim 19 adımı altı katmanda topladım. Her birinde yapay zekânın tipik olarak ne yaptığını, senin ne yapman gerektiğini ve prompt'una ekleyebileceğin cümleyi bulacaksın. Önce rakamlara bakalım.

Neden "çalışıyor" yetmez?

Bir dil modeli, kendisinden isteneni üretmek üzere eğitilir. "Kullanıcı giriş yapabilsin" dediğinde giriş yapılabilen bir ekran alırsın. "Giriş denemeleri sınırlansın, şifreler Argon2 ile saklansın, hatalı girişte kullanıcı adının var olup olmadığı belli olmasın" demediğin sürece bunlar büyük olasılıkla gelmez. Güvenlik, kimsenin istemediği ama herkesin varsaydığı bir gereksinimdir.

Veracode'un 2025 raporu bunun ölçülebilir olduğunu gösterdi: güvenli ve güvensiz iki yol arasında seçim yapabildiği durumlarda modeller vakaların %45'inde güvensiz olanı seçti. Daha çarpıcı olanı, modeller sözdizimi açısından her yıl daha iyi kod yazarken güvenlik başarısının yerinde saymasıydı.

İşin insan tarafı da var. Stanford'dan bir ekip, katılımcılara aynı güvenlik görevlerini yapay zekâ asistanıyla ve asistansız çözdürdü:

En tehlikelisi ikinci madde: aşırı güven. Kod hızlı geldiği için doğru da geldiğini varsayıyoruz. 2025 yılı, bu varsayımın bedelini birkaç kez açıkça gösterdi.

Bu olayların hiçbiri sıfırıncı gün açığı ya da devlet destekli bir saldırı değildi. Hepsi, aşağıdaki listede adı geçen temel kontrollerden birinin ya da birkaçının eksikliğiydi.

19 kontrol, 6 katman

Listeyi tek tek ezberlemek yerine katmanlar halinde düşünmek işe yarıyor. Bir katman atlatılsa bile arkasında bir başkası durmalı.

Bu liste rastgele değil. OWASP'ın Kasım 2025'te yayımlanan ve 2,8 milyondan fazla uygulamanın verisine dayanan Top 10 listesinin her maddesi, bu 19 kontrolden en az biriyle karşılanıyor:

Katman 1 · Kimlik ve erişim

01 Authentication: kimlik doğrulama

Kimlik doğrulama, "sen kimsin?" sorusunun cevabı. Verizon'un 2025 raporunda ihlallerin en sık başlangıç noktası hâlâ çalınmış ya da kötüye kullanılmış kimlik bilgileri (%22). Yani kapı genelde kırılmıyor; anahtarla açılıyor.

02 Authorization: yetkilendirme

Kimlik doğrulama kim olduğunu söyler; yetkilendirme ne yapabileceğini. OWASP listesinde "Broken Access Control" 2021'de de birinciydi, 2025'te de birinci. Vibe-coded uygulamalardaki en yaygın hata, yetki kontrolünün yalnızca arayüzde yapılması: yönetici butonu normal kullanıcıya gösterilmiyor ama endpoint herkese açık. EnrichLead'de ücretli özelliklerin atlatılması tam olarak buydu.

Kural basit: her istek, sunucuda, varsayılan olarak reddedilir; açıkça izin verilen kontrol edilir.

# Kötü: kontrol yalnızca ön yüzde
@api_view(["DELETE"])
def delete_course(request, pk):
    Course.objects.filter(pk=pk).delete()

# İyi: sunucuda, her istekte
@api_view(["DELETE"])
@permission_classes([IsAuthenticated, IsCourseAdmin])
def delete_course(request, pk):
    course = get_object_or_404(Course, pk=pk, organization=request.user.organization)
    course.delete()

IBM'in 2025 raporu bunun yapay zekâ sistemlerinin kendisi için de geçerli olduğunu gösteriyor: yapay zekâ modeli ya da uygulaması ihlali yaşayan kurumların %97'sinde yapay zekâya özgü erişim kontrolleri yoktu.

03 IDOR ve sahiplik kontrolü

/api/faturalar/1043 adresini açabiliyorsan 1044'ü de deneyebilirsin. Sunucu "bu fatura bu kullanıcının mı?" diye sormuyorsa, başkasının faturasını görürsün. Buna IDOR (Insecure Direct Object Reference) deniyor ve otomatik tarayıcıların en zor yakaladığı, saldırganların ise en kolay bulduğu açıklardan biri.

# Kötü: herhangi bir faturayı döndürür
invoice = Invoice.objects.get(pk=pk)

# İyi: sorgu sahibiyle sınırlı; başkasınınki için 404
invoice = get_object_or_404(Invoice, pk=pk, owner=request.user)

UUID kullanmak tahmini zorlaştırır ama sahiplik kontrolünün yerini tutmaz. Ön yüz doğrudan veritabanıyla konuşuyorsa (Supabase, Firebase) bu kontrol veritabanı seviyesinde, Row-Level Security ile yapılmalı. Lovable vakası, bu politikanın eksik olduğu durumu gösteriyor.

Katman 2 · Girdi ve çıktı

04 Input validation: girdi doğrulama

Tarayıcıdaki doğrulama kullanıcı deneyimi içindir, güvenlik için değil. Saldırgan formunu kullanmaz; isteği doğrudan atar. Her girdi sunucuda tip, uzunluk, biçim ve aralık açısından doğrulanmalı. Mümkünse izin listesiyle: "neyi yasaklayayım?" değil, "neyi kabul edeyim?"

Sık atlanan bir tür de mass assignment: modelin tüm alanlarını kabul eden bir serializer, kullanıcının isteğe "is_admin": true eklemesine kapı açar.

class ProfileSerializer(serializers.ModelSerializer):
    class Meta:
        model = Profile
        fields = ["display_name", "bio", "avatar"]   # açıkça say
        read_only_fields = ["role", "is_verified"]

05 SQL injection koruması

ORM kullanıyorsan büyük ölçüde korunursun. Yapay zekâ ise tam ORM'in yetmediği yerlerde, yani dinamik filtreler, arama ve sıralama gibi durumlarda, ham SQL'e geçip değeri metnin içine gömmeye meyillidir.

# Kötü: kullanıcı girdisi sorgunun parçası olur
cursor.execute(f"SELECT * FROM products WHERE name LIKE '%{q}%'")

# İyi: parametreli sorgu
cursor.execute("SELECT * FROM products WHERE name LIKE %s", [f"%{q}%"])

# Sıralama sütunu parametre olamaz: izin listesi kullan
order = {"fiyat": "price", "tarih": "created_at"}.get(sort, "created_at")

06 XSS koruması

Veracode'un testlerinde modeller XSS'e karşı güvenli kod üretmekte en çok zorlandı: vakaların %86'sında başarısız oldular.

Modern şablon motorları (Django, Jinja, React) çıktıyı varsayılan olarak kaçışlar. Açık, bu korumayı bilerek kapattığın yerlerde doğar: Django'da |safe ve mark_safe, React'te dangerouslySetInnerHTML, Vue'da v-html, düz JavaScript'te innerHTML. Zengin metin göstermek zorundaysan HTML'i bir izin listesiyle temizle (Python'da nh3, tarayıcıda DOMPurify) ve arkasına bir Content Security Policy koy.

Bu blog da böyle çalışıyor: yazdığım Markdown, sayfaya basılmadan önce nh3 ile temizleniyor. Yönetici hesabım ele geçirilse bile bir yazının içine <script> gömülemiyor.

07 Dosya yükleme doğrulaması

"Profil fotoğrafı yükle" özelliği, sunucuna dosya yazma yetkisi vermek demek. Uzantıya bakmak yetmez; foto.jpg.php ya da içinde script olan bir SVG, uzantı kontrolünden geçer.

• Dosyanın içeriğini doğrula (sihirli baytlar ya da görseli gerçekten açmayı deneyerek).
• Boyut sınırı koy; dosya adını rastgele üret, kullanıcının verdiği adı kullanma.
• Dosyaları web kökünün dışında ya da ayrı bir depolama alanında tut; asla çalıştırma.
• Depolama alanının erişim kurallarını kontrol et. Tea vakasında sızıntı, kimsenin bakmadığı açık bir depolama alanından geldi.

Katman 3 · Tarayıcı ve taşıma

08 HTTPS

Bugün HTTPS bir tercih değil, varsayılan. Let's Encrypt ücretsiz; Vercel, Render, Railway gibi platformlar sertifikayı kendiliğinden kuruyor. Kontrol etmen gerekenler şunlar: HTTP isteklerinin HTTPS'e yönlendirilmesi, HSTS başlığıyla tarayıcının bir daha HTTP denememesi ve uygulama bir proxy arkasındaysa isteğin gerçekten HTTPS ile geldiğini bilmesi.

SECURE_SSL_REDIRECT = True
SECURE_HSTS_SECONDS = 31536000
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

09 Secure cookies

Oturum çerezi, hesabın anahtarıdır. Üç bayrak bu anahtarı korur:

Yapay zekâ token'ı sık sık localStorage'a yazar. Orası sayfadaki her script'in erişebildiği bir alan; tek bir XSS açığı oturumu da götürür. Oturumu HttpOnly bir çerezde tutmak daha güvenli bir varsayılan. Girişten sonra oturum kimliğini yenilemeyi de unutma.

10 CORS yapılandırması

CORS, saldırganı durduran bir duvar değil. Tarayıcının "farklı kökenden okumaya" koyduğu kısıtı gevşetmenin kuralları. Yapay zekâ bir CORS hatası gördüğünde en hızlı çözümü önerir: allow_origins=[""]. Çerezlerle birlikte çalışmadığı için bir sonraki adımda gelen Origin başlığını olduğu gibi geri yansıtır. Bu, her sitenin kullanıcın adına API'ne istek atıp cevabı okuyabilmesi demek.

11 Security headers: güvenlik başlıkları

Birkaç HTTP başlığı, tarayıcıya "bu sayfada neye izin var?" sorusunun cevabını verir. Kurması on dakika sürer, bir sürü saldırı sınıfını baştan kapatır.

Sonucu securityheaders.com ya da Mozilla Observatory ile kontrol edebilirsin.

Katman 4 · Uygulama davranışı

12 Rate limiting: istek sınırlama

Sınırı olmayan bir giriş formu, saniyede binlerce şifre denenebilecek bir kapıdır. Sınırı olmayan bir yapay zekâ endpoint'i ise başkasının senin faturanla çalıştırdığı bir modeldir. EnrichLead'de API anahtarlarının kotası bu yüzden tükendi.

Sınır koyman gereken yerler: giriş, şifre sıfırlama, OTP doğrulama, kayıt, e-posta ve SMS gönderen her şey ve pahalı işlemler (LLM çağrıları, dosya dönüştürme, dışa aktarma). Bu sitede yönetici girişine IP başına 15 dakikada 5 hatalı deneme, PDF üretimine dakikada 10 istek sınırı var.

13 Global exception handling: hata yönetimi

OWASP 2025'te ilk kez ayrı bir kategori açtı: Mishandling of Exceptional Conditions. İki riski var. Birincisi, hatanın kullanıcıya fazla şey anlatması: yığın izi, SQL sorgusu, dosya yolları, kütüphane sürümleri. İkincisi daha sinsi: hata anında sistemin açık kalması (fail open). Yetki kontrolü bir istisna fırlattığında isteğin geçmesine izin veren bir kod, kontrolsüz koddan daha tehlikelidir.

14 Logging ve audit log

İhlal fark edilmeden geçen her gün, saldırgana kazandırılmış bir gündür. Log, "ne oldu?" sorusunun tek cevabı. Ama yanlış log da risk: Veracode'un testlerinde modeller log injection'a karşı vakaların %88'inde güvensiz kod üretti; kullanıcı girdisini temizlemeden log'a yazmak, sahte log satırları üretmenin yolunu açar.

• Kaydet: başarılı ve başarısız girişler, yetki reddi, yönetici işlemleri, veri dışa aktarma, ayar değişiklikleri. Her kayıtta kim, ne, ne zaman, nereden ve sonuç.
• Kaydetme: şifreler, token'lar, tam kart numaraları, gereğinden fazla kişisel veri.
• Logları uygulama sunucusundan ayrı bir yerde tut ve kritik olaylara alarm kur.

Bu sitede her giriş denemesi ayrı bir güvenlik log'una düşüyor; ziyaretçi sayacı ise IP adresini hiç saklamıyor, yalnızca tuzlanmış bir özetini tutuyor.

Katman 5 · Veri ve sırlar

15 Secret management: gizli anahtar yönetimi

API anahtarı, veritabanı şifresi, ödeme sağlayıcısı anahtarı. Bunların koda girmesi, vibe coding'in en sık ve en pahalı hatası.

Vibe coding'e özgü bir tuzak daha var: ön yüz framework'lerinde NEXT_PUBLIC_ ya da VITE_ önekiyle başlayan her değişken tarayıcıya giden pakete gömülür. Yapay zekâ bir değişkeni "çalışsın" diye bu önekle tanımladığında, gizli anahtarın herkesin görebileceği bir JavaScript dosyasına girer.

• Secret'lar .env'de, .env ise .gitignore'da. Canlıda platformun secret yöneticisi.
• Gizli anahtar gerektiren her çağrı sunucudan yapılır; tarayıcı yalnızca senin backend'inle konuşur.
• Commit öncesi tarama (gitleaks, ggshield) kur.
• Bir secret sızdıysa commit'i silmek yetmez: anahtarı hemen iptal et ve yenisini üret.

16 Veritabanı güvenliği

Uygulamanın veritabanı kullanıcısı tablo silebiliyor mu? Veritabanı internete açık mı? Geliştirme ile canlı aynı veritabanı mı? Replit vakasında bu sorulardan sonuncusunun cevabı "evet"ti. Sonrasında platform, geliştirme ve canlı veritabanlarını otomatik olarak ayırmaya başladı.

• En az yetki: uygulama kullanıcısı yalnızca ihtiyaç duyduğu tablolarda okuma ve yazma yapabilsin; şema değişikliği ayrı bir kullanıcıyla.
• Veritabanı yalnızca uygulamanın ağından erişilebilir olsun; bağlantılar TLS ile.
• Ön yüz veritabanına doğrudan bağlanıyorsa RLS ya da güvenlik kuralları her tabloda açık olsun.
• Yapay zekâ ajanlarına canlı veritabanı kimlik bilgisi verme. Ajan geliştirme ortamında çalışsın; canlıya giden her değişiklik insan onayından geçsin.

17 Yedekleme

Yedek, diğer 16 kontrolün başarısız olduğu gün devreye giren kontrol. Sophos'un 2024 araştırmasına göre fidye yazılımı saldırısından sonraki ortalama toparlanma maliyeti, fidye hariç 2,73 milyon dolar. Replit vakasının mutlu sonla bitmesinin tek nedeni de bir yedeğin var olmasıydı.

İki sayıyı baştan belirle: ne kadar veri kaybını göze alabilirsin (RPO) ve ne kadar sürede ayağa kalkman gerekir (RTO). Yedekleme sıklığın ve yöntemin bu iki cevaptan çıkar.

Katman 6 · Tedarik zinciri ve süreç

18 Dependency scanning: bağımlılık taraması

Yazdığın kodun büyük kısmı aslında senin değil; kurduğun paketlerin. Sonatype, Kasım 2023'ten itibaren bir yıl içinde 512.847 kötü amaçlı açık kaynak paket tespit etti; bir önceki yıla göre %156 artış.

Yapay zekâ buna yeni bir risk ekledi: olmayan paketler. USENIX Security 2025'te yayımlanan bir çalışma, 16 modelin ürettiği 576.000 kod örneğini inceledi. Önerilen paketlerin yaklaşık beşte biri gerçekte yoktu. Üstelik aynı uydurma isimler tekrar tekrar önerildiği için saldırgan bu isimleri önceden kaydedip içine zararlı kod koyabiliyor. Buna slopsquatting deniyor.

• Yapay zekânın önerdiği her paketi kurmadan önce kayıt sayfasına bak: gerçekten var mı, kim yayınlıyor, kaç indirme almış, ne zamandan beri var?
• Lock dosyasını (package-lock.json, poetry.lock) depoya ekle.
• npm audit, pip-audit, OSV-Scanner ve Dependabot ya da Renovate ile bilinen açıkları sürekli tara.

19 CI/CD güvenlik taraması

Son kontrol, diğerlerinin bir kez yapılıp unutulmamasını sağlıyor. Her push'ta çalışan bir pipeline, insanın gözden kaçırdığını yakalar ve daha önemlisi, yeni gelen kodun eskiyi bozmasını engeller.

# .github/workflows/security.yml
name: security
on: [push, pull_request]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install pip-audit bandit
      - run: pip-audit -r requirements.txt
      - run: bandit -r . -x ./tests -ll

Pipeline'ın kendisi de bir saldırı yüzeyi: CI secret'larını en az yetkiyle tanımla, üçüncü parti action'ları bir sürüme ya da commit'e sabitle ve permissions alanını açıkça yaz.

Nereden başlamalı?

On dokuz madde göz korkutabilir. Hepsi aynı anda gerekmiyor; ama bir kısmı olmadan yayına çıkmak, kapıyı açık bırakıp tatile gitmek gibi.

Son bir öneri: yapay zekâya güvenliği yazdırmak yerine sor. Kod üretildikten sonra aynı modele, ayrı bir konuşmada, bu listeyi verip kendi kodunu denetlemesini iste. Üreten model ile denetleyen bakış açısı ayrıldığında, ilk turda kaçan şeylerin önemli bir kısmı yakalanıyor. Yine de son karar, kodu okuyan bir insanda kalmalı.

Yapay zekâ, çok hızlı ve çok istekli bir yardımcı. Ama hızlı yazılan kod, okunmadan yayına giden koddur. Hız güvenliğin önüne geçmesin.

Kaynaklar

1. Veracode, 2025 GenAI Code Security Report, Temmuz 2025.
2. N. Perry, M. Srivastava, D. Kumar, D. Boneh, Do Users Write More Insecure Code with AI Assistants?, ACM CCS 2023.
3. J. Spracklen ve diğerleri, We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025.
4. GitGuardian, The State of Secrets Sprawl 2025.
5. GitGuardian, The State of Secrets Sprawl 2026 (The Hacker News özeti), Mart 2026.
6. OWASP, OWASP Top 10:2025.
7. IBM, Cost of a Data Breach Report 2025, Temmuz 2025.
8. Verizon, 2025 Data Breach Investigations Report.
9. Sonatype, 10th Annual State of the Software Supply Chain Report, Ekim 2024.
10. Sophos, The State of Ransomware 2024.
11. NIST NVD, CVE-2025-48757.
12. Escape.tech, How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms.
13. OECD AI Incidents Monitor, Replit AI coding tool deletes live production database, Temmuz 2025.
14. BleepingComputer, Tea app leak worsens with second database exposing user chats, Temmuz 2025.
15. Indie Hackers, Vibe coding has a security problem, 2025.