AI ile Geliştirilen Uygulama Güvenli mi?

Temel Değerlendirme

AI ile geliştirilen bir uygulama güvenli olabilir; ancak yalnızca çalışıyor olması production'a hazır olduğu anlamına gelmez. Cursor, Claude, ChatGPT veya AI app builder araçları kod üretimini hızlandırır ama auth, tenant isolation, secret yönetimi, API abuse, dependency riski, logging ve iş mantığı güvenliği gibi kararları otomatik olarak doğru çözmez. AI ile çıkan uygulama, canlıya alınmadan önce insan uzmanlığıyla tehdit modeli, kod incelemesi ve güvenlik testi görmelidir.

AI ile Kod Yazmak Sorun Değil; Sahiplik Boşluğu Sorun

AI destekli geliştirme artık istisna değil. Geliştiriciler boilerplate kodu daha hızlı çıkarıyor, ürün ekipleri prototipleri günler içinde ayağa kaldırıyor, küçük ekipler daha önce kuramayacağı backendleri kurabiliyor. Bu iyi bir şey.

Güvenlik problemi AI'ın kod yazması değil. Problem, ortaya çıkan kodun kimin tarafından, hangi güvenlik standardına göre, hangi threat model ile doğrulandığının belirsiz olmasıdır.

Bir AI aracı size login ekranı, database modeli, admin paneli, API route'ları ve deployment dosyası üretebilir. Fakat şu soruları kendiliğinden doğru cevaplamayabilir:

• Kullanıcı başka bir tenant'ın verisine erişebilir mi?
• Refresh token çalınırsa ne olur?
• Admin işlemleri audit log üretiyor mu?
• API endpoint'i pahalı bir işlemi sınırsız tetikleyebilir mi?
• Secret değerleri loglara veya client bundle içine düşüyor mu?
• Database query'leri authorization bağlamını gerçekten içeriyor mu?
• AI agent bir tool çağırırken hangi yetkiyle hareket ediyor?

Bu soruların cevabı "kod derlendi" veya "uygulama çalışıyor" ile verilmez.

AI App Builder ile Üretilen Uygulamalarda En Sık Riskler

1. Auth Var Ama Authorization Eksik

AI araçları login ve session akışını hızlı kurabilir. Ancak birçok gerçek ihlal login eksikliğinden değil, nesne seviyesinde yetki kontrolünün unutulmasından doğar.

Örneğin kullanıcı kendi faturasını görmek için şu endpoint'i çağırıyor olabilir:

GET /api/invoices/inv_123
Authorization: Bearer <token>

Backend sadece kullanıcının giriş yapıp yapmadığını kontrol edip inv_123 kaydını döndürüyorsa BOLA/IDOR riski oluşur. Doğru kontrol, faturanın mevcut kullanıcının tenant veya organization sınırı içinde olduğunu da doğrulamalıdır.

AI ile yazılan kodlarda bu hata sık görülür çünkü araç genellikle mutlu yolu tamamlamaya odaklanır. "Bu kullanıcı bu nesne üzerinde bu işlemi yapabilir mi?" sorusu ayrı bir güvenlik tasarımı ister.

2. Tenant Isolation Modeli Belirsizdir

Çok kiracılı SaaS uygulamalarında en kritik güvenlik sınırı tenant isolation'dır. AI araçları tenantId alanı ekleyebilir ama bu alanın her sorguda, cache key'de, queue job'da ve file path'te tutarlı kullanıldığını garanti etmez.

Riskli örnek:

const project = await db.project.findUnique({
  where: { id: projectId },
});

Daha güvenli yaklaşım:

const project = await db.project.findFirst({
  where: {
    id: projectId,
    tenantId: session.tenantId,
  },
});

Bu küçük fark, SaaS güvenliğinde müşteri verisinin başka müşteriye sızıp sızmayacağını belirler.

3. Secret Yönetimi Geliştirme Hızına Kurban Gider

AI ile hızlı geliştirme sırasında .env dosyaları, API key'ler, test tokenları ve provider secretları kolayca koda, loglara veya deploy ayarlarına karışabilir. Özellikle geliştirici AI asistana "bu hatayı çöz" diye terminal çıktısı, stack trace veya config dosyası yapıştırdığında secret sızıntısı git'e düşmeden de gerçekleşebilir.

Kontrol edilmesi gereken yerler:

• Git geçmişi
• CI/CD environment değişkenleri
• Build logları
• Error tracking araçları
• Docker image layer'ları
• Frontend bundle
• AI assistant prompt geçmişi

Secret scanning yalnızca repository taraması değildir; geliştirme sürecinin tamamını kapsamalıdır.

4. API Abuse ve Maliyet Saldırıları Düşünülmez

AI ile geliştirilen uygulamalar genellikle hızlıca çalışan endpoint'lere sahip olur. Fakat üretimde her endpoint aynı maliyette değildir.

Basit bir profil endpoint'i ucuzdur. Fakat şu işlemler pahalıdır:

• LLM analizi
• Embedding üretimi
• PDF/CSV export
• Büyük MongoDB aggregation
• E-posta veya SMS gönderimi
• Dosya dönüştürme
• Üçüncü parti API çağrıları

Saldırganın amacı uygulamayı düşürmek değil, faturanızı şişirmek olabilir. Bu yüzden rate limit sadece IP başına istek sayısı değildir. Kullanıcı, tenant, endpoint maliyeti ve işlem türüne göre kota uygulanmalıdır.

5. Error Handling Fazla Konuşur

AI tarafından üretilen backendlerde hata mesajları çoğu zaman geliştirici deneyimi için ayrıntılı bırakılır. Bu production'da risklidir.

Kötü hata mesajı:

{
  "error": "Prisma failed on table users_private_tokens with connection string..."
}

Güvenli hata mesajı:

{
  "error": "Request could not be completed",
  "requestId": "req_8f31..."
}

Detaylar logda kalabilir; kullanıcıya dönen cevap saldırgana sistem haritası vermemelidir.

Production Öncesi AI Uygulama Güvenlik Kontrol Listesi

| Alan | Sorulacak soru | Risk | |---|---|---| | Auth | Access ve refresh token yaşam döngüsü net mi? | Account takeover | | Authorization | Her kaynak tenant/user bağlamında kontrol ediliyor mu? | BOLA / IDOR | | Secrets | Secretlar git, log, image ve frontend bundle dışında mı? | Credential leak | | API abuse | Pahalı endpointler maliyet bazlı limitleniyor mu? | Cost attack | | Dependencies | AI'ın seçtiği paketler güvenilir mi? | Supply chain | | Database | Query'lerde tenant filtresi zorunlu mu? | Cross-tenant leak | | Queue | Worker tekrar authorization yapıyor mu? | Async privilege bypass | | Logging | PII ve tokenlar maskeleniyor mu? | Data leak | | Admin panel | Kritik işlemler audit ve step-up auth istiyor mu? | Privilege abuse | | AI agent/tool | Agent hangi tool'u hangi yetkiyle çağırıyor? | Agentic misuse |

Bu liste minimum başlangıçtır. Regüle sektörlerde ek olarak KVKK/GDPR, finansal işlem bütünlüğü, logging retention, incident response ve vendor risk kontrolleri gerekir.

Yanlış Bilinenler

"AI daha güvenli kod yazar"

AI bazen daha temiz kod yazar; fakat güvenli kod yazması bağlama bağlıdır. Yanlış prompt, eksik gereksinim veya belirsiz threat model varsa AI güvenlik kararlarını tahmin eder.

"Framework güvenliyse uygulama da güvenlidir"

Next.js, Node.js, Django, FastAPI veya Supabase güvenli kullanılabilir. Ancak framework, sizin business logic hatanızı otomatik düzeltmez.

"Login varsa veriler korunur"

Login authentication'dır. Veri koruması authorization, tenant isolation ve resource policy gerektirir.

"Pentest sadece büyük şirketler için gerekir"

AI ile hızlı geliştirilen küçük SaaS'lar da müşteri verisi, ödeme, API key ve üretim altyapısı taşır. Risk büyüklüğü ekip büyüklüğüne değil, sistemin neye eriştiğine bağlıdır.

Pratik Örnek: AI ile Yapılmış SaaS Dashboard

Bir ekip AI app builder ile müşteri raporlama paneli geliştiriyor. Uygulamada login, proje listesi, fatura görüntüleme, CSV export ve AI özetleme özelliği var.

İlk bakışta ürün çalışıyor. Ancak güvenlik incelemesinde şu riskler çıkabilir:

• GET /api/reports/:id başka tenant raporunu döndürüyor.
• CSV export endpoint'i sınırsız tarih aralığı kabul ediyor.
• AI özetleme endpoint'i tenant başına token kotası tutmuyor.
• Error loglarında müşteri e-postaları ve API response'ları ham halde saklanıyor.
• Admin rolü sadece frontend menüden gizlenmiş, backend policy yok.
• Worker job payload'ında tenant doğrulaması tekrar yapılmıyor.

Bu hataların hiçbiri uygulamanın "çalışmasını" engellemez. Tam tersine, demo sırasında ürün sorunsuz görünür. Güvenlik problemi gerçek kullanıcı, gerçek veri ve gerçek saldırı senaryosu geldiğinde ortaya çıkar.

Ne Zaman Profesyonel Destek Gerekir?

Şu durumlardan biri varsa AI ile geliştirilen uygulama canlıya çıkmadan önce profesyonel güvenlik incelemesi görmelidir:

• Müşteri veya çalışan verisi işliyorsa
• Çok kiracılı SaaS modeli varsa
• Ödeme, fatura, finansal işlem veya PII taşıyorsa
• AI agent e-posta, dosya, CRM, GitHub veya Slack'e bağlıysa
• RAG sistemi iç dokümanlara erişiyorsa
• Admin panel veya API key yönetimi varsa
• Üçüncü parti providerlara otomatik işlem yaptırıyorsa
• Regülasyon veya müşteri güvenlik talebi varsa

Bu noktada sadece otomatik scanner yeterli değildir. Kod, mimari, iş mantığı ve canlı saldırı senaryoları birlikte test edilmelidir.

Okuyucunun Bir Sonraki Adımı

Eğer AI ile geliştirdiğiniz bir uygulama varsa, önce üç dosya çıkarın:

1. Veri haritası: Hangi veri nerede saklanıyor ve kim erişiyor?
2. Yetki matrisi: Hangi rol hangi kaynağa hangi işlemle erişebilir?
3. Kritik endpoint listesi: Hangi endpoint pahalı, hassas veya admin etkili?

Bu üç doküman olmadan güvenlik testi dağınık kalır. Bunlar hazır olduğunda kod inceleme, API testi, secret scanning, dependency review ve business logic testleri çok daha verimli yapılır.

Kısa Özet

AI ile uygulama geliştirmek hız kazandırır; güvenlik sorumluluğunu ortadan kaldırmaz. En büyük risk AI'ın kod yazması değil, ekiplerin çalışan prototipi güvenli production sistemi sanmasıdır. Auth, authorization, tenant isolation, secret yönetimi, API maliyeti, logging ve dependency güvenliği doğrulanmadan AI ile üretilen uygulama canlıya alınmamalıdır.

Eresus Security, AI ile geliştirilen web uygulamaları, SaaS panelleri, agentic workflow'lar ve RAG tabanlı sistemler için production öncesi güvenlik değerlendirmesi yapar. Uygulamanız hızlı çıktıysa, saldırganlardan önce biz test edelim.

İçerik Kontrol Listesi

Bu içerik neden people-first?

Okuyucunun gerçek karar anına cevap veriyor: "AI ile yaptığım uygulamayı yayına alabilir miyim?" Teorik AI tartışması yerine production öncesi kontrol listesi, pratik örnek ve karar ölçütleri veriyor.

Bu içerik nerede özgün?

AI kod güvenliğini sadece "AI kötü kod yazar" klişesine indirmiyor. Sahiplik boşluğu, tenant isolation, maliyet saldırısı, queue authorization ve AI assistant prompt sızıntısı gibi pratik riskleri tek karar çerçevesinde topluyor.

Nerede deneyim/uzmanlık sinyali veriyor?

BOLA, session mimarisi, secret yönetimi, API abuse, queue worker ve logging gibi gerçek pentest ve backend review alanlarını somut örneklerle açıklıyor.

Hangi bölümler güncellenmeli?

• AI coding araçlarının veri saklama politikaları
• OWASP LLM ve OWASP API listeleri
• Popüler framework güvenlik varsayılanları
• Yeni agent/tool entegrasyon riskleri

Hangi iç linklerle desteklenmeli?

• /tr/blog/ai-coding-assistants-security-risks
• /tr/blog/backend-auth-session-mimarisi
• /tr/blog/api-bola-idor-uzman-rehberi
• /tr/blog/nodejs-api-ai-bot-ddos-maliyet-saldirilari
• /tr/services/web-app-pentest
• /tr/services/ai-security

Sık Sorulan Sorular

Bu konuda ilk adım ne olmalı?

Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.

Profesyonel destek ne zaman gerekir?

Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.