# Yapay Zekâ ile Geliştirilen Uygulamalarda Güvenlik: Yayın Öncesi Kontroller

> Yapay zekâ ile geliştirilen bir uygulama yayına alınmadan önce gizli anahtarların istemci kodundan ve kod deposundan çıkarıldığı, yetki kontrollerinin sunucu tarafında uygulandığı, veritabanı erişim kurallarının varsayılan olarak kapalı yapılandırıldığı, girdilerin sunucuda doğrulandığı ve bağımlılıkların tarandığı somut testlerle doğrulanmalıdır. Uygulama bir dil modeli özelliği içeriyorsa istem enjeksiyonuna karşı yetki sınırlaması, kullanıcı onayı ve çıktı denetimi gerekir. Kişisel veri işleniyorsa bu kontroller, 6698 sayılı Kanun'un 12. maddesindeki teknik ve idari tedbir yükümlülüğünün de parçasıdır.

Kaynak: https://dijitalreklammerkezi.com/blog/yapay-zeka-ile-gelistirilen-uygulamalarda-guvenlik  
Yayımlayan: Dijital Reklam Merkezi (DRM Yayın Kurulu)  
Tarih: 2026-10-16

Yapay zekâ ile geliştirilen uygulamalarda güvenlik, dil modellerinin ve yapay zekâ destekli geliştirme ortamlarının ürettiği kodun, uygulama kullanıcılara açılmadan önce bilinen saldırı yollarına karşı denetlenmesini ifade eder. Bir uygulamanın yapay zekâ yardımıyla kısa sürede çalışır hâle gelmesi; gizli anahtarların korunduğu, verilere yalnızca yetkili kişilerin erişebildiği ve girdilerin güvenli biçimde işlendiği anlamına gelmez.

Bu rehber, kodlama deneyimi sınırlı olsa da yapay zekâ araçlarıyla ürün geliştiren bireyler ve küçük ekipler için hazırlanmıştır. Yaklaşımın hangi projelere uygun olduğu sorusu için [kod yazmadan uygulama geliştirmenin olanaklarını ve sınırlarını ele alan YazılımaOrg rehberine](https://yazilima.org/blog/kod-yazmadan-uygulama-gelistirme) başvurulabilir. Burada odak, yayın öncesi güvenlik kontrolleridir; metinde geçen kavramların tanımlarına [DRM Sözlüğü](https://dijitalreklammerkezi.com/sozluk) üzerinden ulaşılabilir.

## Yapay zekâ ile üretilen kodda hangi güvenlik açıkları sık görülür?

Dil modelleri, eğitildikleri kod örneklerindeki kalıpları yeniden üretir; bu örneklerin bir bölümü eski ya da güvensizdir. Model ayrıca talimatın amacına odaklanır: istenen özellik çalışır, ancak talimatta belirtilmeyen güvenlik gereksinimleri çoğu zaman kendiliğinden eklenmez.

Sık karşılaşılan açık türleri şunlardır:

- **Açıkta bırakılan gizli bilgiler:** API anahtarlarının veya parolaların tarayıcı koduna ya da kod deposuna yazılması.
- **Yalnızca arayüzde uygulanan kısıtlar:** Bir düğmenin gizlenip ilgili işlemin sunucuda yetki kontrolü olmadan bırakılması.
- **Gevşek veritabanı kuralları:** Geliştirme kolaylığı için açılan geniş izinlerin yayındaki sürümde unutulması.
- **Doğrulanmayan girdiler:** Formlardan veya dosya yüklemelerinden gelen verilerin kontrol edilmeden işlenmesi.
- **Denetlenmeyen bağımlılıklar:** Önerilen her paketin var olduğunun ve güvenilir olduğunun varsayılması.

Bu açıklar yapay zekâya özgü değildir; ancak geliştirme hızlandıkça gözden kaçma olasılıkları artar. Ekip ortamındaki inceleme ve test adımları [yazılım ekiplerinde yapay zekâ destekli geliştirmeyi ele alan yazımızda](https://dijitalreklammerkezi.com/blog/yazilim-ekiplerinde-yapay-zeka-destekli-gelistirme) incelenmektedir.

## Gizli anahtarlar istemci tarafında neden bırakılmamalıdır?

Tarayıcıda veya mobil uygulamada çalışan kod kullanıcının cihazına indirilir ve incelenebilir; istemci tarafına yazılan bir anahtar bu nedenle gizli sayılamaz. Bir model API anahtarının veya ödeme sağlayıcısı anahtarının açığa çıkması, hesabınız üzerinden başkalarının işlem yapmasına yol açabilir.

Burada bir ayrım yapılmalıdır: Bazı hizmetlerin istemci yapılandırmasındaki tanımlayıcılar (ör. Firebase web yapılandırmasındaki proje anahtarı) tasarım gereği herkese açıktır ve koruma sunucu tarafındaki erişim kurallarıyla sağlanır. Gizli anahtarlar ise yalnızca sunucuda veya ortam değişkenlerinde tutulmalıdır.

- Gizli anahtar gerektiren çağrılar sunucu tarafındaki bir uç noktaya veya sunucusuz fonksiyona taşınmalıdır.
- `.env` gibi dosyalar sürüm kontrolü dışında tutulmalı, depoda gizli bilgi taraması etkinleştirilmelidir.
- Açığa çıkmış olabilecek bir anahtar dosyadan silinmekle yetinilmeden iptal edilip yenilenmelidir; silinen bilgi sürüm geçmişinde kalır.
- Gerçek anahtarlar ve müşteri verileri, yapay zekâ aracına verilen talimatlara yazılmamalıdır.

## Kimlik doğrulama, yetkilendirme ve veritabanı kuralları nasıl kontrol edilir?

Kimlik doğrulama kullanıcının kim olduğunu, yetkilendirme ise neye erişebileceğini belirler. Sık görülen sorunlardan biri, yetkilendirmenin yalnızca arayüzde uygulanmasıdır.

### Kimlik doğrulama

Parola saklama ve oturum yönetiminin sıfırdan yazdırılması yerine yerleşik kimlik doğrulama hizmetlerinin (ör. Firebase Authentication veya Supabase Auth) kullanılması riski azaltır. Kişisel Verileri Koruma Kurumu'nun [kullanıcı güvenliğine ilişkin tavsiye edilen tedbirleri açıklayan kamuoyu duyurusu](https://www.kvkk.gov.tr/Icerik/7177/Kullanici-Guvenligine-Iliskin-Veri-Sorumlulari-Tarafindan-Alinmasi-Tavsiye-Edilen-Teknik-ve-Idari-Tedbirlere-Iliskin-Kamuoyu-Duyurusu) da çift kademeli kimlik doğrulama, HTTPS, parolaların güncel özetleme (hash) algoritmalarıyla saklanması ve başarısız giriş denemelerinin sınırlandırılması gibi önlemleri sıralamaktadır.

### Yetkilendirme

Her istekte, kullanıcının ilgili kayda erişme hakkı sunucu tarafında kontrol edilmelidir. Basit bir test şöyledir: İki test hesabı açılır; birinci hesapla oturum açıkken ikinci hesaba ait bir kaydın kimlik numarası adrese veya isteğe yazılır. Kayıt görüntülenebiliyorsa nesne düzeyinde yetkilendirme açığı vardır.

### Veritabanı erişim kuralları

Firebase Security Rules veya Supabase'deki satır düzeyinde güvenlik (Row Level Security) politikaları, istemcinin veritabanına doğrudan bağlandığı mimarilerde temel savunma hattıdır. Kurallar "varsayılan olarak kapalı" ilkesine göre yazılmalı, her koleksiyon veya tablo için okuma ve yazma yetkisi açıkça tanımlanmalıdır. Firebase belgeleri, herkese okuma ve yazma izni veren kural setinin üretim ortamında kullanılmaması konusunda uyarmaktadır. Kurallar, oturum açmamış kullanıcı ve başka kullanıcı senaryoları için simülatörde denenmelidir.

### Girdi doğrulama

Kullanıcıdan gelen her veri güvenilmeyen veri kabul edilmeli, asıl doğrulama sunucuda yapılmalıdır. Parametreli sorgular kullanılmalı, sayfada gösterilen kullanıcı içeriği kodlanarak aktarılmalı, dosya yüklemelerinde tür ve boyut sınırı, giriş ve form uç noktalarında istek sınırı (rate limiting) uygulanmalıdır.

## Bağımlılık ve paket güvenliği nasıl sağlanır?

Akademik çalışmalar, kod üreten dil modellerinin zaman zaman var olmayan paket adları önerebildiğini ve bu adların bir kısmının tekrar tekrar üretildiğini göstermiştir. Kötü niyetli kişilerin bu adlarla paket yayımlaması "slopsquatting" olarak anılan bir tedarik zinciri riskini doğurur; popüler paketlere benzer adlı sahte paketler (typosquatting) de bilinen bir risktir.

1. Önerilen paketin resmî paket deposunda (npm, PyPI vb.) bulunduğu; yayımcısı, güncellenme geçmişi ve kullanım yaygınlığı kontrol edilmelidir.
2. Yazım farkı içeren veya yeni yayımlanmış benzer adlı paketlere karşı dikkatli olunmalıdır.
3. Sürümler kilit dosyasıyla (ör. `package-lock.json`) sabitlenmelidir.
4. `npm audit`, `pip-audit` veya kod deposu sağlayıcısının bağımlılık uyarılarıyla bilinen açıklar düzenli taranmalıdır.
5. Kullanılmayan paketler kaldırılmalıdır.

## Uygulamaya yapay zekâ özelliği eklendiğinde hangi önlemler alınmalıdır?

Sohbet asistanı veya belge özetleme gibi bir dil modeli özelliği ek bir risk taşır: istem enjeksiyonu (prompt injection). Bu saldırıda kullanıcı mesajına ya da modelin işlediği belge veya web sayfasına yerleştirilen talimatlar, modelin geliştirici kurallarını göz ardı etmesine yol açar.

OWASP'ın [büyük dil modeli ve üretken yapay zekâ uygulamaları için yayımladığı 2025 ilk 10 risk listesi](https://genai.owasp.org/llm-top-10/), istem enjeksiyonunu LLM01 koduyla listenin başında sınıflandırır. Listede hassas bilgi ifşası (LLM02), uygunsuz çıktı işleme (LLM05), aşırı yetki (LLM06), sistem isteminin sızması (LLM07) ve sınırsız kaynak tüketimi (LLM10) de yer alır.

İstem enjeksiyonuna karşı kesin bir önleme yöntemi bulunduğu söylenemez; önlemler, saldırı başarılı olsa bile zararı sınırlayacak biçimde tasarlanmalıdır:

- Sistem istemine gizli anahtar veya iç bilgi yazılmamalıdır.
- Modele yalnızca görevi için gereken araç ve veri erişimi verilmelidir (en az yetki ilkesi).
- E-posta gönderme, kayıt silme veya ödeme gibi geri alınamaz işlemler kullanıcı onayına bağlanmalıdır.
- Model çıktısı güvenilmeyen veri gibi ele alınmalı, doğrudan sorguya veya sayfa koduna aktarılmamalıdır.
- Model çağrıları sunucudan yapılmalı, kullanıcı başına istek ve harcama sınırı tanımlanmalıdır.

## Kayıt, yedekleme ve olay müdahalesi KVKK açısından neden önemlidir?

Güvenlik, bir sorunun fark edilmesini ve verilerin geri getirilebilmesini de kapsar. Giriş denemeleri, yetki hataları ve yönetici işlemleri kaydedilmeli; parolalar ve gereksiz kişisel veriler kayıtlara yazılmamalıdır. Veritabanı düzenli yedeklenmeli, yedekten geri dönüş en az bir kez denenmelidir. Yetkisiz erişim şüphesinde kimin ne yapacağı ve kimlere bildirim yapılacağı önceden yazılı hâle getirilmelidir.

Kişisel veri işleniyorsa bu hazırlık hukuki bir boyut kazanır. 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, veri sorumlusunun kişisel verilerin hukuka aykırı işlenmesini ve bunlara hukuka aykırı erişilmesini önlemek ve verilerin muhafazasını sağlamak amacıyla uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri almasını öngörür. Veriler veri sorumlusu adına başka bir kişi tarafından işleniyorsa bu tedbirler bakımından müşterek sorumluluk doğar (m.12/2). Verilerin kanuni olmayan yollarla başkalarınca elde edilmesi hâlinde durum en kısa sürede ilgili kişiye ve Kurula bildirilir (m.12/5); Kişisel Verileri Koruma Kurulu'nun 24.01.2019 tarihli ve 2019/10 sayılı kararı, Kurula bildirim için 72 saatlik süre öngörmektedir. Kanun'un 18. maddesi, bu yükümlülükleri yerine getirmeyenler hakkında idari para cezası düzenler.

Aydınlatma ve açık rıza gibi diğer yükümlülükler [yapay zekâ ile geliştirilen uygulamalarda yasal yükümlülükleri ele alan yazımızda](https://dijitalreklammerkezi.com/blog/yapay-zeka-ile-gelistirilen-uygulamalarda-yasal-yukumlulukler), çerezlere ilişkin kurallar ise [KVKK kapsamında çerez politikasını inceleyen rehberimizde](https://dijitalreklammerkezi.com/blog/kvkk-cerez-politikasi-dijital-reklam) ele alınmaktadır.

## Yayın öncesi güvenlik kontrol listesi

Bir kontrol, son sütundaki doğrulama gerçekten yapıldığında tamamlanmış sayılır. Yapay zekâ aracından güvenlik incelemesi istemek yararlı bir ön adımdır, ancak bu doğrulamaların yerini tutmaz.

| Kontrol | Neden | Nasıl doğrulanır |
|---|---|---|
| Gizli anahtarlar yalnızca sunucuda | İstemci kodu herkesçe incelenebilir | Tarayıcı geliştirici araçlarında kaynak dosyalar ve ağ istekleri incelenir |
| Açığa çıkmış anahtarlar yenilendi | Silinen anahtar sürüm geçmişinde kalır | Sağlayıcı panelinde eski anahtarın iptali görülür |
| Yetki kontrolü sunucuda | Arayüz kısıtları atlatılabilir | İki test hesabıyla birbirinin kayıtlarına erişim denenir |
| Veritabanı kuralları varsayılan olarak kapalı | Açık kurallar tüm veriyi açığa çıkarabilir | Simülatörde oturumsuz ve başka kullanıcı senaryoları denenir |
| Girdiler sunucuda doğrulanıyor | Enjeksiyon ve betik saldırılarını önler | Formlara özel karakter, uzun metin ve beklenmeyen dosya girilir |
| Giriş uç noktalarında istek sınırı | Parola deneme saldırılarını sınırlar | Kısa sürede çok sayıda istek gönderilir |
| Bağımlılıklar doğrulandı ve tarandı | Var olmayan veya zararlı paket riski | Denetim aracında kritik uyarı kalmadığı görülür |
| Yapay zekâ özelliğinde yetki ve onay sınırları | İstem enjeksiyonunun etkisini sınırlar | Kuralları yok saymaya yönelik test girdileri denenir |
| Kullanım ve harcama sınırları | Kontrolsüz maliyeti önler | Sağlayıcı panelinde limitler kontrol edilir |
| Yedekleme ve olay müdahale planı | Verinin geri getirilmesi ve bildirim süresine uyum | Yedekten geri dönüş denenir; plan güncel mi kontrol edilir |

## Ne zaman profesyonel güvenlik incelemesi gerekir?

Kontrol listesi her riski ortadan kaldırmaz. Aşağıdaki durumlarda deneyimli bir güvenlik uzmanınca kod incelemesi veya sızma testi yapılması önerilir:

- Uygulama ödeme alıyor veya finansal işlem yapıyorsa.
- Özel nitelikli kişisel veriler ya da çok sayıda kişiye ait veriler işleniyorsa.
- Kurumsal müşteriler güvenlik değerlendirmesi talep ediyorsa.
- Yapay zekâ özelliği e-posta gönderme veya kayıt değiştirme yetkisine sahipse.
- Bir güvenlik olayı yaşanmışsa.

İnceleme kapsamı için OWASP'ın Uygulama Güvenliği Doğrulama Standardı (ASVS) başvuru çerçevesi olarak kullanılabilir. Küçük ekiplerde yapay zekâ araçlarıyla paylaşılabilecek verilerin yazılı kurallarla belirlenmesi de önerilir; bu kuralların kapsamı [kurumsal yapay zekâ kullanım politikasını ele alan yazımızda](https://dijitalreklammerkezi.com/blog/kurumsal-yapay-zeka-kullanim-politikasi) açıklanmaktadır.

Gizli bilgilerin ayrıştırılması ve veritabanı kurallarının yazılması gibi güvenli geliştirme alışkanlıklarının eğitim sürecinde, gerçek projeler üzerinde kazanılması sonradan yapılacak düzeltmelerden daha az maliyetlidir. Bu yaklaşıma örnek olarak, DRM akreditasyonuna sahip [yazilima.org](https://yazilima.org) platformunun AI Academy kapsamında sunduğu [yapay zeka ile yazılım geliştirme eğitimi](https://yazilima.org/ai-academy) incelenebilir. Kodlama ön bilgisi gerektirmeyen program dört hafta, sekiz canlı ders ve üç projeden oluşmakta; Google Antigravity, Claude, Gemini ve Firebase gibi araçlarla yürütülmektedir.

## Sıkça Sorulan Sorular

### Yapay zekâ ile üretilen kod güvenli midir?

Kendiliğinden güvenli ya da güvensiz değildir; sonuç talimata ve yapılan doğrulamaya bağlıdır. Belirtilmeyen güvenlik gereksinimleri çoğu zaman eklenmediğinden kod yayın öncesinde ayrıca kontrol edilmelidir.

### API anahtarı tarayıcı koduna yazılırsa ne olur?

Anahtar, uygulamayı açan herkes tarafından görülebilir ve kullanılabilir. Anahtar iptal edilmeli, yenisi yalnızca sunucuda saklanmalıdır.

### Prompt injection nedir ve nasıl önlenir?

Prompt injection (istem enjeksiyonu), kullanıcı girdisi veya dış içerik yoluyla dil modelinin geliştirici kurallarını göz ardı etmeye yönlendirilmesidir. Model yetkileri sınırlandırılmalı, kritik işlemler kullanıcı onayına bağlanmalı ve model çıktısı güvenilmeyen veri gibi ele alınmalıdır.

### Küçük bir uygulama için KVKK veri güvenliği yükümlülüğü geçerli midir?

Evet. 6698 sayılı Kanun'un 12. maddesi, yükümlülüğü uygulamanın büyüklüğüne göre değil veri sorumlusu sıfatına göre düzenler. E-posta adresi gibi kişisel veriler toplayan küçük bir uygulamanın sahibi de uygun tedbirleri almakla yükümlüdür.

### Yapay zekâ aracından güvenlik incelemesi istemek yeterli midir?

Hayır. Yararlı bir ön adımdır, ancak araç bazı açıkları gözden kaçırabilir. Kontroller test hesapları, kural simülatörü ve bağımlılık taramasıyla doğrulanmalıdır.

## Kaynaklar

- 6698 sayılı Kişisel Verilerin Korunması Kanunu — Resmî Gazete 07.04.2016, Sayı 29677 (m.12, m.18)
- Kişisel Verileri Koruma Kurulu — Kişisel Veri İhlali Bildirim Usul ve Esaslarına İlişkin 24.01.2019 Tarihli ve 2019/10 Sayılı Karar
- Kişisel Verileri Koruma Kurumu — Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler) — https://www.kvkk.gov.tr
- Kişisel Verileri Koruma Kurumu — Kullanıcı Güvenliğine İlişkin Veri Sorumluları Tarafından Alınması Tavsiye Edilen Teknik ve İdari Tedbirlere İlişkin Kamuoyu Duyurusu, 15.02.2022
- OWASP — Top 10 for LLM Applications 2025 — https://genai.owasp.org/llm-top-10/
- OWASP — Application Security Verification Standard (ASVS)
- Firebase — Get Started with Cloud Firestore Security Rules (ürün belgeleri)
- Spracklen, J. ve diğerleri — We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security Symposium 2025 (arXiv:2406.10279)