Yapay zekayla yazılan uygulamayı yayına almadan önce güvenlik kontrol listesi

Yapay zeka ile üretilen bir uygulamayı yayına almadan önce sekiz nokta var, gerçekten kapalı mı diye bakman gereken: sunucu tarafı kimlik doğrulama, veritabanı erişimi, sızan anahtarlar, dosya yükleme, ödeme webhook'u, girdi doğrulama, hata takibi ve yedekleme. Her madde iki şekilde biter: testi geçer ya da kalır. Aşağıda kalan her madde için ilk yapman gereken yazıyor.

Genel bir güvenlik kontrol listesi senin kurulumunu bilmiyor. Hangi yapay zeka aracıyla yazıldığını, hangi veritabanını kullandığını, ödeme akışın olup olmadığını sormuyor. Bu liste özellikle yapay zeka üreten kod tabanları için yazıldı: her madde ne aradığını, nasıl test edeceğini ve testi geçemezsen ilk yapman gerekeni söylüyor.

Kimlik doğrulama: kontrol tarayıcıda mı sunucuda mı

Test: uygulamanın korumalı bir API uç noktasını tarayıcıyı atlayıp doğrudan çağır. Oturum çerezi ya da token vermeden bir curl isteği at, örneğin curl https://uygulaman.com/api/siparisler. Cevap gerçek veri döndürüyorsa, kontrol sadece arayüzde yapılıyor demektir.

Geçti: sunucu 401 ya da 403 döner, veri gelmez. Kaldı: veri geliyor, arayüzdeki "giriş yap" ekranı sadece görsel bir engelmiş. Yapay zeka araçları formu, listeyi, butonu doğru çiziyor ama yetki kontrolünü genelde arayüz bileşenine gömüyor, isteğin kendisine değil. Düzeltme: her istekte oturumu sunucu tarafında doğrula, arayüzdeki kontrole güvenme.

Veritabanı erişimi: RLS politikası gerçekten çalışıyor mu

Supabase kullanan bir projede test şu: veritabanına anon rolüyle bağlan, set local role anon; çalıştır, sonra select * from profiles; dene. Politika doğruysa Postgres bunu 42501 hata koduyla reddediyor, sorgu çalışmadan önce.

Geçti: anon rolüyle sorgu reddediliyor ya da sadece kendi satırların dönüyor. Kaldı: tüm tablo geliyor, RLS kapalı ya da politika eksik demektir. Düzeltme: tabloda RLS'i aç, auth.uid() ile kullanıcıyı satıra bağlayan bir politika yaz, sonra testi tekrar çalıştır.

Anahtarlar: hangi sır nerede duruyor

Test: yayına aldığın build'i al, tarayıcıya giden JS dosyalarını tara. Build klasöründe şunu çalıştır: grep -rEo "(sk_live_|sk_test_|service_role|whsec_)[A-Za-z0-9_]*" .next/static. Bu desen Stripe gizli anahtarlarının, bir Supabase servis rolü token'ının ve webhook sırlarının en sık görülen öneklerini yakalıyor.

Geçti: hiç eşleşme yok, ya da eşleşenler yukarıdaki gibi kendi arayüz metnin. Kaldı: gerçek bir token deseni eşleşiyor, örneğin sk_live_51... gibi bir dize. Düzeltme: anahtarı hemen rotate et, sunucu tarafı ortam değişkenine taşı, grep'i tekrar çalıştırarak doğrula.

Dosya yükleme: tip, boyut, erişim sınırı var mı

Test: bir dosyayı uzantısını değiştirerek yükle, bir metin dosyasını .jpg gibi göster. Ardından beklenenden çok büyük bir dosya dene, birkaç yüz megabayt. Sunucu ikisini de kabul ediyorsa, doğrulama sadece dosya adına bakıyor demektir.

Geçti: sunucu dosyanın gerçek imzasını kontrol ediyor, tipi doğruluyor, boyutu sınırlıyor. Kaldı: her ikisi de geçiyor. Düzeltme: dosya imzasını (magic bytes) sunucu tarafında doğrula, boyut sınırı koy, yüklenen dosyaları herkese açık kök dizinin dışında tut.

Ödeme webhook'u: imza doğrulanıyor mu

Test: webhook uç noktana Stripe-Signature başlığı olmadan ya da uydurma bir imzayla bir POST isteği gönder. Sunucu isteği işliyorsa, imza kontrolü yok demektir.

Geçti: sunucu 400 döner, isteği reddeder. Stripe'ın resmi kütüphanesi imzayı zaman damgası ve HMAC-SHA256 ile doğruluyor, varsayılan beş dakikalık toleransın dışındaki isteği de reddediyor. Kaldı: istek her koşulda işleniyor. Düzeltme: iş mantığına dokunmadan önce resmi kütüphaneyle imza doğrulamasını ekle.

Girdi doğrulama ve oran sınırlama: kaç istekte kırılıyor

Test: aynı uç noktaya kısa sürede art arda elli istek gönder. Hiçbiri engellenmiyorsa oran sınırlama yok demektir. Ayrıca forma normalde göndermeyeceğin bir değer yolla, negatif bir fiyat ya da olması gerekenden çok daha uzun bir metin gibi.

Geçti: bir eşikten sonra istekler 429 ile geri çevriliyor, form sunucu tarafında da doğrulanıyor. Kaldı: hepsi geçiyor. Düzeltme: oran sınırlama ekle, istemci tarafındaki doğrulamayı sunucuda da tekrarla. İstemciye asla güvenme.

Loglama: uygulama patladığında haberin oluyor mu

Test: kasıtlı olarak bir hata tetikle, bozuk bir istek gönder ya da geçersiz bir alan doldur. Ardından hata takip aracına (Sentry gibi) ya da doğrudan sunucu loguna bak.

Geçti: hata bir dakika içinde panelinde görünüyor. Kaldı: kullanıcı bir hata görüyor ama sende hiçbir kayıt yok. Düzeltme: yayına almadan önce bir hata takip aracı bağla, ilk kesintiden sonra değil.

Yedek ve geri dönüş: veri kaybını test ettin mi

Test: yedeğin var olduğunu doğrulamak yetmiyor. Bir yedeği gerçekten ayrı bir ortama geri yükle, süreç uçtan uca çalışıyor mu bak.

Geçti: geri yükleme çalıştı, veri eksiksiz geldi. Kaldı: yedek hiç denenmemiş ya da geri yükleme yarıda kalıyor. Düzeltme: point-in-time recovery'i aç, geri yükleme provasını takvime bağla.

Geçti/kaldı tablosu: hangi sırayla kapatırsın

Sekiz test bitince elinde bir liste kalıyor. Hepsini aynı anda kapatmana gerek yok, ama sıra önemli. Kullanıcı verisine doğrudan erişimi olan maddeler önce gelir.

Bu kontrol listesinin sınırı

Bu sekiz madde önce kapatman gerekenler, hepsi değil. Bu liste gerçek bir güvenlik denetiminin, sızma testinin ya da uyumluluk incelemesinin yerini tutmaz. Sekizini de geçmek, her RLS politikasının her rolü kapsadığı ya da checkout akışının bir yerinde iş mantığı hatası kalmadığı anlamına gelmiyor. Elle yapılan testler dışarıdan görüneni yakalıyor. Kodu okuyan birinin yerini tutmuyor.

Sekiz maddeyi tek tek elle test etmek yerine yönlendirmeli sorularla hızlıca geçmek istersen, yapay zeka uygulaması yayına hazırlık kontrolü aracımız aynı kategorileri 11 soru halinde soruyor ve bulguları şiddetine göre sıralıyor. RLS ve sızan anahtar açıklarının nereden geldiğini daha detaylı görmek istersen Lovable ve Bolt uygulamalarının açıkta bıraktıkları yazımıza bak. Projeyi henüz Lovable'dan taşımadıysan, önce kodu GitHub'a çıkarma rehberimiz işine yarar.

Listedeki kritik maddeler hâlâ açıksa ve kendi başına kapatamıyorsan, yapay zeka projesi tamamlama hizmetimiz tam bu noktadan devralıyor.

Sık sorulan sorular

Bu kontrol listesi hangi araçlarla yapılan uygulamalar için geçerli?
Lovable, Bolt, v0, Cursor, Replit ya da Base44 gibi araçlarla üretilen uygulamaların çoğu benzer bir backend kalıbı kullanıyor, genelde Supabase ya da benzeri bir servis. Sekiz madde bu kalıba göre yazıldı.

Testleri kaç dakikada bitiririm?
Sekiz maddeyi tek tek elle çalıştırırsan 30-40 dakika sürüyor. Komutların çoğu bir terminal ve bir curl isteği kadar basit.

Hiçbirini kendim çalıştıramıyorsam ne yaparım?
Komutları kendin çalıştıramıyorsan, bulguları yorumlayacak birine ihtiyacın var demektir. Aracımızın sonuç ekranı her maddeyi kendi başına anlaşılır anlatıyor, ama kritik bir açığı kapatmak teknik bir iş.

RLS sadece Supabase için mi geçerli?
Terim Supabase'den geliyor ama fikir her veritabanı için aynı: satır bazlı erişim kontrolü. Firebase'in güvenlik kuralları ve düz bir Postgres'te politika bazlı erişim aynı işi görüyor.

Geri yükleme testini riske girmeden nasıl yaparım?
Prodüksiyonu değil, ayrı bir ortamı kullan. Yedeği oraya geri yükle, verinin eksiksiz geldiğini doğrula, sonra o ortamı sil.