AI Tarafından Oluşturulan Kodu Güvenli Hale Alma — Vibe Coding Güvenlik Kontrol Listesi

Claude veya Cursor ile vibe-code yöntemiyle bir uygulama geliştirdin ve bunu ödeme yapan bir müşteriye teslim etmek üzeresin, dur. AI tarafından üretilen kod öngörülebilir güvenlik açıklarıyla birlikte gelir — açığa çıkan API anahtarları, eksik giriş doğrulaması, herhangi bir kullanıcının diğer herkinin verilerini görmesine izin veren varsayılan veritabanı izinleri. Bunlar kenar durumlar değildir. Neredeyse her ilk geçiş AI tarafından üretilen kod tabanında ortaya çıkarlar.

Bu kılavuz, ürünü başlatmadan önceki güvenlik kontrol listesidir. Hiçbir gerçek kullanıcı uygulamaya erişmeden önce adım adım takip edin. En yaygın vibe coding yığını için yazılmıştır (Next.js + Supabase + Vercel), ancak ilkeler kullandığınız araçlardan bağımsız olarak geçerlidir.

AI Tarafından Üretilen Kodun Neden Güvenlik Sorunları Vardır

AI modelleri "çalışıyor mu?" için değil "güvenli mi?" için optimize ediyor. Claude'a "kullanıcı hesapları içeren bir görev yöneticisi oluştur" dediğinde, kullanıcı oluşturan, görevleri depolayan ve bunları görüntüleyen kod üretecek. Muhtemelen otomatik olarak yapmayacağı şeyler: Kullanıcı A'nın Kullanıcı B'nin görevlerini görmemesini sağlamak, giriş alanlarının kötü niyetli komut dosyası kabul etmemesini doğrulamak, API anahtarlarınızı tarayıcının geliştirici araçlarından gizlemek veya birisi uç noktalarınıza saldırmayı önlemek için hız sınırlaması eklemek.

Bunlar AI'nın başarısızlıkları değildir — bunlar istem içindeki boşluklardır. AI'ı istediğiniz şeyi yapar. Muhtemelen güvenliği sormadınız çünkü özellikler üzerinde yoğunlaştınız. Şimdi geri dönüp güvenliği eklemenin zamanı geldi.

1. Adım: Ortam Değişkenlerinizi Denetleyin

Bu, vibe-code yapılmış uygulamalarda en yaygın ve en tehlikeli hata. Projenizde kodlanmış API anahtarları, veritabanı URL'leri veya sırlar için her dosyayı kontrol edin.

Neye bakmalısınız: sk-, eyJ, sbp_, supabase, postgres:// ile başlayan dizeleri veya rastgele görünen uzun dizeleri kod tabanında arayın. Bu dosyaları özellikle kontrol edin: /app veya /pages dizininde herhangi bir dosya, herhangi bir bileşen dosyası, next.config.js ve herhangi bir yardımcı dosya.

Çözüm: Her sırrı ortam değişkenlerine taşıyın. Next.js'de, yalnızca NEXT_PUBLIC_ öneki olan değişkenler tarayıcıya açık tutulur. Veritabanı URL'niz, hizmet rolü anahtarınız ve API sırlarınız hiçbir zaman bu ön eke sahip olmamalıdır.

# .env.local (BU DOSYAYI ASLA GÖNDERMEYİN)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Bunlar tarayıcıya açık tutmak için sorun değil:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Doğrulayın: .gitignore dosyanızın .env.local içerdiğini kontrol edin. Sırları Git'e zaten gönderdiyseniz, silindikten sonra bile bunlar geçmişinizde vardır — açığa çıkan her anahtarı hemen döndürün (yeniden oluşturun).

2. Adım: Supabase'de Satır Düzeyinde Güvenliği Etkinleştirin

Supabase kullanıyorsanız, bu tek en kritik adımdır. Varsayılan olarak, Supabase tablolarında erişim kısıtlaması yoktur — anonKey'iniz olan herkes her tablodaki her satırı okuyup yazabilir. Bu, Kullanıcı A'nın basit bir API çağrısıyla Kullanıcı B'nin verilerini görebileceği anlamına gelir.

Çözüm: Her tabloda Satır Düzeyinde Güvenliği (RLS) etkinleştirin, ardından erişimi kısıtlayan politikalar oluşturun.

Supabase panelinize gidin → Tablo Editörü → her tabloyu seçin → "RLS Devre Dışı" öğesini tıklayın. Ardından politikalar ekleyin:

Kullanıcıların yalnızca kendi verilerini görmesi gereken tipik bir uygulama için, bir SELECT politikası oluşturun: auth.uid() = user_id. INSERT, UPDATE ve DELETE için benzer politikalar oluşturun.

Test edin: Kullanıcı A olarak giriş yapın, API aracılığıyla Kullanıcı B'nin verilerine erişmeyi deneyin. Görebiliyorsanız, politikalarınız yanlıştır. Supabase, politikaları doğrudan test edebileceğiniz bir SQL editörüne sahiptir.

Yaygın AI hatası: Claude sık sık anon anahtarı yerine service_role anahtarını kullanan Supabase sorguları oluşturur (RLS'i atlar). İstemci tarafı kodunuzun yalnızca anonKey kullandığını kontrol edin. Hizmet rolü anahtarı yalnızca sunucu tarafı kodunda (API yolları, sunucu eylemleri) bulunmalı ve hiçbir zaman tarayıcıya açık tutulmamalıdır.

3. Adım: Kimlik Doğrulamayı Düzgün Şekilde Ekleyin

AI tarafından üretilen auth kodu sık sık çalışır ancak kısayollar alır. Bu spesifik sorunları kontrol edin:

Oturum yönetimi: Oturumların sona erdiğinden emin olun. Kimlik doğrulama kurulumunuzun makul bir oturum zaman aşımı içerdiğini kontrol edin (Supabase varsayılanları genellikle iyidir, ancak doğrulayın). Çıkışın yalnızca yerel tanımlama bilgisini temizlemediğini, oturumu gerçekten geçersiz kıldığını sağlayın.

Parola gereksinimleri: Email/parola kimlik doğrulamanız varsa, minimum parola uzunluğunu (8+ karakter) zorunlu kılın. Supabase bunu proje ayarlarınızda → Kimlik Doğrulama → Parola Gereksinimleri'nde işler.

Korumalı rotalar: Kullanıcıya özel veriler gösteren her sayfanın kimlik doğrulama ara yazılımı gerekir. Next.js App Router'da, geçerli bir oturumu kontrol eden ve kimliği doğrulanmamış kullanıcıları giriş sayfasına yönlendiren bir ara yazılım oluşturun. Yalnızca istemci tarafı kontrollere güvenmeyin — bir kullanıcı API'nizi doğrudan çağırarak bunları atlatabilir.

Email doğrulaması: Supabase Auth ayarlarında email onayını etkinleştirin. Bu, insanların sahte e-posta adresleriyle hesap oluşturmasını engeller ve hesap geçerliliğinin temel bir katmanını ekler.

4. Adım: Tüm Girdileri Doğrulayın

AI tarafından üretilen formlar genellikle temel doğrulamaya (gerekli alanlar, email biçimi) sahiptir ancak nadiren kötü niyetli girişlere karşı koruma sağlar.

Eklenecek şeyler:

Her API uç noktasında sunucu tarafı doğrulama. Hiçbir zaman yalnızca istemci tarafı doğrulamaya güvenmeyin — API'nize doğrudan istek göndererek atlatılabilir. TypeScript için Zod gibi bir doğrulama kitaplığını kullanarak uygulamanızın kabul ettiği her veri parçasını tanımlayın.

Tarayıcıda görüntülenen herhangi bir kullanıcı tarafından oluşturulan içeriğin HTML'sini temizleyin. Uygulamanızın yorumları, açıklamaları veya tarayıcıda işlenen herhangi bir metin alanı varsa, tehlikeli komut dosyalarını kaldırmak için DOMPurify gibi bir kitaplık kullanın. Bunu olmadan, birisi diğer kullanıcıların oturumlarını çalan JavaScript kodu enjekte edebilir (site içi komut dosyası / XSS).

Uygulamanız dosya yüklemelerini kabul ediyorsa dosya yükleme boyutu ve türlerini sınırlandırın. AI tarafından üretilen yükleme işleyicileri sık sırasında sınırlı olmayan sınırlama anlamına gelir, birisi 2GB dosya veya çalıştırılabilir dosya yükleyebilir. Boyut sınırları ekleyin (çoğu uygulama için 5MB makuldur) ve dosya türlerini gerçekten ihtiyaç duyduklarınızla sınırlandırın (resimler, PDF'ler vb.).

5. Adım: API Rotalarınızı Güvenli Hale Getirin

Uygulamanızdaki her API rotası veya sunucu eylemi için bu sorunları kontrol edin:

Her uç noktada kimlik doğrulama. Kullanıcı verilerini döndüren veya değiştiren her API rotası öncelikle kullanıcının oturumunu doğrulamalıdır. AI sık sırasında herhangi birinden istekleri kabul eden API rotaları oluşturur.

Kimlik doğrulamadan ötesinde yetkilendirme. Bir kullanıcının oturum açtığını doğruladıktan sonra bile, istediği belirli kaynağa erişmek için yetkili olup olmadığını doğrulayın. "Kullanıcı A oturum açtı" "Kullanıcı A, Kullanıcı B'nin profilini düzenleyebilir" anlamına gelmez. Her veri erişiminde sahipliği kontrol edin.

Hız sınırlaması. Hız sınırlaması olmadan, birisi verilerinizi kaşımak veya sunucunuzu boğmak için saniyede binlerce istekİ API'nize gönderebilir. rate-limiter-flexible gibi bir kitaplık kullanarak veya Vercel'in Edge İşlevlerinde yerleşik hız sınırlamasını kullarak temel hız sınırlaması ekleyin.

HTTP yöntemleri. API rotalarınızın yalnızca yanıt vermesi gereken HTTP yöntemlerine yanıt verdiğinden emin olun. POST isteklerini işleyen bir rota, açıkça tasarlamadığınız sürece DELETE isteklerine de yanıt vermemelidir.

6. Adım: Dağıtım Yapılandırmanızı Kontrol Edin

Dağıtım platformunuzun AI'ın yapılandırmadığı güvenlik ayarları vardır.

Kontrol edilecek Vercel ayarları: "Dağıtım Korumasını" etkinleştirin (ön izleme dağıtımlarını görüntülemek için kimlik doğrulama gerektirir — istemcilerin yanlışlıkla devam eden işi ortaya çıkaran ön izleme URL'lerini paylaşmasını engeller). Trafiği ani artışlar varsa beklenmeyen ücretleri önlemek için harcama limitleri belirleyin. CORS başlıklarında izin verilen etki alanlarını yapılandırın.

Özel alan ve SSL: Bunu bir müşteriye teslim ediyorsanız, özel etki alanlarını HTTPS ile ayarlayın. Vercel ve Netlify SSL'i otomatik olarak işler. Hiçbir zaman istemci uygulamasını bir .vercel.app alt etki alanında teslim etmeyin — profesyonel görünmez ve müşteri bunu kolayca aktaramaz.

Başlıklar: next.config.js veya vercel.json dosyanıza güvenlik başlıkları ekleyin: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (sitenizin iframe'lere gömülmesini ve tıklama dolandırıcılığını engeller), Strict-Transport-Security (HTTPS'yi zorunlu kılar). Bunlar, tüm saldırı sınıflarını önleyen tek seferlik eklemelerdir.

7. Adım: Son Güvenlik Taraması Yapın

Herhangi bir şeyi müşteriye teslim etmeden önce bu ücretsiz kontrolleri yapın:

npm audit: Proje dizininizde npm audit çalıştırın. Bağımlılıklarınızdaki bilinen güvenlik açıklarını işaretler. Kritik ve yüksek şiddetli sorunları düzeltin. Mevcut olan otomatik düzeltmeler için npm audit fix çalıştırın.

Lighthouse: Dağıtılmış sitenizi Chrome'da açın, DevTools'u açın, Lighthouse denetimi çalıştırın. "En İyi Uygulamalar" puanını kontrol edin — eksik HTTPS, güvenilmeyen kitaplıklar ve güvensiz başlıklar gibi yaygın güvenlik sorunlarını yakalar.

Manuel test: Bir kullanıcı olarak giriş yapın, URL'leri veya API çağrılarını değiştirerek diğer kullanıcının verilerine erişmeyi deneyin. Boş formlar, boyut aşan girdiler ve özel karakterler (kodlanmış XSS yükleri gibi) gönderin. Bunlardan herhangi biri işe yarıyorsa, düzeltilecek sorunlarınız var.

Ürünü Başlatmadan Önceki Kontrol Listesi

Bunu yazdırıp canlıya gitmeden önce her öğeyi kontrol edin:

• Tüm sırlar ortam değişkenlerinde (kodlanmış anahtarlar yok)
• .env.local in .gitignore içinde (ve Git geçmişinde sır yok)
• Supabase RLS'i her tabloda etkin
• RLS politikaları test edildi (Kullanıcı A, Kullanıcı B'nin verilerini göremez)
• İstemci tarafı kodu yalnızca anonKey'i kullanır (hizmet rolü anahtarı yalnızca sunucu tarafında)
• Her API rotasında kimlik doğrulama
• Veri erişiminde yetkilendirme kontrolleri (sahiplik doğrulaması)
• Her formda giriş doğrulaması (yalnızca istemci tarafı değil, sunucu tarafında)
• Dosya yükleme sınırları (varsa boyut ve tür)
• API uç noktalarında hız sınırlaması
• Yapılandırılmış güvenlik başlıkları
• npm audit çalıştırıldı ve kritik sorunlar düzeltildi
• Özel alan SSL ile yapılandırıldı
• Ön izleme dağıtımları korunmuş
• Manuel çapraz kullanıcı veri erişim testi geçildi

Sonuç

Vibe-code yapılmış bir uygulamayı güvenli hale getirmek, güvenlik uzmanı olmak anlamına gelmez. AI'ın geride bıraktığı tahmin edilebilir boşlukları yakalayan bir kontrol listesinden geçmek anlamına gelir. Yukarıdaki adımlar 2–4 saat sürer ve en yaygın güvenlik açıklarını engeller. Müşteriye yönelik bir uygulama için, bu isteğe bağlı değildir — bu profesyonel çalışma ile sorumluluk arasındaki farktır.

İlk vibe-code uygulamanızı oluşturuyorsanız, vibe coding hakkında eksiksiz kılavuzumuzla başlayın. Claude veya Cursor ile kullandığınız istemi iyileştirmek istiyorsanız, ücretsiz istemi optimize etme aracımızı deneyin. En iyi kodlama araçlarının bir dökümü için Claude Code vs Codex yazısını görmüştür.

Açıklama: Bu makaledeki bazı bağlantılar bağlantı ortağı bağlantılarıdır. Yalnızca kişisel olarak test ettiğimiz ve düzenli olarak kullandığımız araçları öneriyoruz. Tam açıklama politikamız için bkz.