Vibe-Coded Bir Uygulamayı Müşterilere Vermeden Önce Nasıl Güvenli Hale Getirilir

Claude veya Cursor ile bir uygulama geliştirdiyseniz ve bunu ödeme yapan bir müşteriye teslim etmek üzeresiniz, durun. AI tarafından üretilen kod öngörülebilir güvenlik açıklarıyla birlikte gelir — açık API anahtarları, eksik giriş doğrulaması, herhangi bir kullanıcının diğer tüm kullanıcıların verilerini görmesine izin veren varsayılan veritabanı izinleri. Bunlar edge case değildir. Neredeyse her ilk geçişte AI tarafından üretilen kod tabanında meydana gelirler.

Bu kılavuz, ön yayın güvenlik kontrol listesidir. Gerçek bir kullanıcı uygulamanıza dokunmadan önce bunu adım adım izleyin. 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 "işe yarıyor mu?" için optimize eder, "güvenli mi?" için değil. Claude'a "bir görev yöneticisi oluştur, kullanıcı hesapları ile" dediğinizde, kullanıcılar oluşturan, görevleri depolayan ve görüntüleyen kod üretecektir. Otomatik olarak muhtemelen yapmayacağı şey: Kullanıcı A'nın Kullanıcı B'nin görevlerini göremeyeceğinden emin olmak, giriş alanlarının kötü niyetli komut dosyaları kabul edemeyeceğini doğrulamak, API anahtarlarınızı tarayıcının geliştirici araçlarından gizlemek veya birisinin uç noktalarınıza saldırmasını önlemek için hız sınırlaması eklemek.

Bunlar AI'nin başarısızlıkları değil — istekteki boşluklar. AI sizin istediğinizi inşa eder. Muhtemelen güvenlik istemediniz çünkü özelliklere odaklandınız. Şimdi geri dönüp bunu ekleme zamanı geldi.

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

Bu, vibe coding uygulamalarında en yaygın ve en tehlikeli hatadır. Projenizin her dosyasında sabit kodlanmış API anahtarları, veritabanı URL'leri veya sırlar olup olmadığını kontrol edin.

Nelere bakmalı: Kodunuzda sk-, eyJ, sbp_, supabase, postgres:// ile başlayan dizeleri veya uzun rastgele görünümlü herhangi bir dizeyi arayın. Bu dosyaları özel olarak kontrol edin: /app veya /pages dizininizdeki 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_ ön ekine sahip değişkenler tarayıcıya sunulur. Veritabanı URL'niz, hizmet rolü anahtarınız ve API sırlarınız bu ön eke asla sahip olmamalıdır.

# .env.local (ASLA bu dosyayı commit etmeyin)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Bunlar tarayıcıya maruz kalmak tamam:
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çerip içermediğini kontrol edin. Git'e zaten sırlar commit ettiyseniz, silinmesinden sonra bile tarihinizdedir — açık kalan her anahtarı hemen döndürün (yeniden oluşturun).

Adım 2: 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ı erişim kısıtlaması olmaz — anon anahtarınıza sahip 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 ilkeler oluşturun.

Supabase gösterge tablonuza gidin → Tablo Editörü → her tabloyu seçin → "RLS Devre Dışı" tıklayın ve etkinleştirin. Ardından ilkeler ekleyin:

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

Test edin: Kullanıcı A olarak oturum açın, API aracılığıyla Kullanıcı B'nin verilerine erişmeye çalışın. Görebiliyorsanız, ilkeleriniz yanlıştır. Supabase, ilkeleri doğrudan test edebileceğiniz bir SQL editörüne sahiptir.

Yaygın AI hatası: Claude, genellikle service_role anahtarını (RLS'yi atlar) kullanan Supabase sorguları üretir, anon anahtarını uygun RLS ilkeleriyle kullanan değil. İstemci tarafı kodunuzun yalnızca anon anahtarını kullandığını kontrol edin. Service role anahtarı yalnızca sunucu tarafı kodunda (API rotaları, sunucu eylemleri) var olmalı ve tarayıcıya asla maruz kalmamalıdır.

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

AI tarafından üretilen auth kodu genellikle işe yarar ancak kısayollar alır. Bu spesifik sorunları kontrol edin:

Oturum yönetimi: Oturumların sona erdiğinden emin olun. Auth kurulumunuzun makul bir oturum zaman aşımı içerip içermediğini kontrol edin (Supabase varsayılanları genellikle iyidir, ancak doğrulayın). Oturumu kapatmanın yerel tanımlama bilgisini temizlemekle değil, gerçekten oturumu geçersiz kıldığından emin olun.

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 ele alır.

Korumalı rotalar: Kullanıcıya özgü veriler gösteren her sayfa, kimlik doğrulama ara yazılımını gerektirir. 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.

E-posta doğrulaması: Supabase Auth ayarlarında e-posta onayını etkinleştirin. Bu, kişilerin sahte e-posta adresleriyle hesap oluşturmasını önler ve hesap geçerliliğinin temel bir katmanını ekler.

Adım 4: Tüm Girişleri Doğrulayın

AI tarafından üretilen formlar genellikle temel doğrulama (zorunlu alanlar, e-posta biçimi) vardır ancak kötü niyetli giriş'e karşı nadiren koruma sağlar.

Eklenecekler:

Her API uç noktasında sunucu tarafı doğrulama. Asla yalnızca istemci tarafı doğrulamaya güvenmeyin — doğrudan API'nize istek göndererek atlatılabilir. Uygulamanızın kabul ettiği her veri parçası için şemalar tanımlamak üzere Zod (TypeScript için) gibi bir doğrulama kitaplığı kullanın.

Tarayıcıda görüntülenen herhangi bir kullanıcı tarafından oluşturulan içerikte HTML'i temizleyin. Uygulamanızda yorumlar, açıklamalar veya tarayıcıda işlenen herhangi bir metin alanı varsa, tehlikeli betikleri temizlemek için DOMPurify gibi bir kitaplık kullanın. Bunu yapmadan, birisi diğer kullanıcıların oturumlarını çalan JavaScript enjekte edebilir (siteler arası komut dosyası çalıştırma / XSS).

Uygulamanız dosya yüklemeleri kabul ediyorsa dosya yükleme boyutunu ve türlerini sınırlayın. AI tarafından üretilen yükleme işleyicileri genellikle sınır olmaz, bu da birinin 2GB dosya veya yürütülebilir bir dosya yükleyebileceği anlamına gelir. Boyut sınırlarını ekleyin (çoğu uygulama için 5MB makuldur) ve dosya türlerini gerçekten ihtiyaç duyduğunuz şeylerle sınırlayın (resimler, PDF'ler, vb.).

Adım 5: 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ı, önce kullanıcının oturumunu doğrulamalıdır. AI, genellikle herkes tarafından istekleri kabul eden API rotaları üretir.

Kimlik doğrulamayı aşan yetkilendirme. Bir kullanıcının oturum açtığını doğruladıktan sonra, istedikleri belirli kaynağa erişmelerine izin verilip verilmediğini 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 API'nize saniyede binlerce istek gönderebilir, ya veri kazımak ya da sunucunuzu doldurmak için. rate-limiter-flexible gibi bir kitaplık kullanarak temel hız sınırlaması ekleyin veya Edge İşlevlerinde Vercel'in yerleşik hız sınırlamasını kullanın.

HTTP yöntemleri. API rotalarınızın yalnızca içermeleri 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.

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

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

Kontrol edilecek Vercel ayarları: "Dağıtım Korumasını" etkinleştirin (önizleme dağıtımlarını görüntülemek için auth gerektirir — müşterilerin yanlışlıkla devam eden çalışmayı ortaya çıkaran önizleme URL'lerini paylaşmasını önler). Trafik artışı varsa beklenmeyen ücretleri önlemek için harcama sınırları belirleyin. CORS başlıklarında izin verilen etki alanlarını yapılandırın.

Özel etki alanı ve SSL: Bunu bir müşteriye teslim ediyorsanız, özel alanlarını HTTPS ile ayarlayın. Vercel ve Netlify SSL'i otomatik olarak ele alırlar. Müşteri uygulamasını asla .vercel.app alt alanında teslim etmeyin — profesyonel görünmez ve müşteri onu kolayca aktaramaz.

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

Adım 7: Son Güvenlik Taraması Çalıştırın

Herhangi bir şeyi bir müşteriye teslim etmeden önce, bu ücretsiz kontrolleri çalıştırın:

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

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

Manuel test: Bir kullanıcı olarak oturum açın, URL'leri veya API çağrılarını değiştirerek başka bir kullanıcının verilerine erişmeye çalışın. Boş formlar, büyük boyutlu girişler ve özel karakterler (kodlanmış XSS yükleri gibi) göndermeyi deneyin. Bunlardan herhangi biri işe yarıyorsa, düzeltilecek sorunlarınız var.

Ön Yayın Kontrol Listesi

Bunu yazdırın ve canlı gitmeden önce her öğeyi kontrol edin:

• Tüm sırlar ortam değişkenlerinde (sabit kodlanmış anahtarlar yok)
• .env.local içinde .gitignore (ve Git geçmişinde sır yok)
• Supabase RLS her tabloda etkinleştirildi
• RLS ilkeleri test edildi (Kullanıcı A, Kullanıcı B'nin verilerini göremez)
• İstemci tarafı kod yalnızca anon anahtarını kullanır (service role 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ı da)
• Uygulanabilirse dosya yükleme sınırları (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 etki alanı SSL ile yapılandırıldı
• Önizleme dağıtımları korunuyor
• Manuel çapraz kullanıcı veri erişim testi geçildi

Sonuç

Vibe coding uygulamasını güvenli hale getirmek, güvenlik uzmanı olmak değildir. AI'nin geride bıraktığı öngörülebilir boşlukları yakalaması gereken bir kontrol listesini çalıştırmakla ilgilidir. Yukarıdaki adımlar 2–4 saat alır ve en yaygın güvenlik açıklarını önler. Müşteriye yönelik bir uygulama için, bu isteğe bağlı değildir — profesyonel çalışma ile sorumluluk arasındaki farktır.

İlk vibe coding uygulamanızı yapıyorsanız, vibe coding'e tam kılavuzumuzdan başlayın. Claude veya Cursor'da kullandığınız istekleri geliştirmek isterseniz, ücretsiz istemi optimize edicimizi deneyin. En iyi kodlama araçlarının dökümü için Claude Code vs Codex'e bakın.

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ıza bakın.