1. Frontend JavaScript'ine gömülü API key'leri
Bu, en yıkıcı ve yapılması en kolay hatadır. AI aracına "Stripe ödemeleri ekle" ya da "OpenAI'ye bağlan" dersin ve secret key'i doğrudan bir istemci bileşenine bağlar. Uygulama çalışır — ve secret key'in artık her ziyaretçinin tarayıcısına gönderilir; DevTools'u açan ya da JS bundle'ında arama yapan herkes tarafından okunabilir.
NEXT_PUBLIC_ (veya VITE_, ya da REACT_APP_) önekli her şey, build zamanında istemci bundle'ına gömülür. Secret key'ler — Stripe sk_live_, OpenAI sk-, veritabanı URL'leri, service-role key'leri — yalnızca sunucu tarafı kodda okunmalıdır: API route'ları, server component'leri veya edge function'lar.
Hızlı kontrol: yayındaki siteni aç, sayfa kaynağına ve paketlenmiş JS'e bak ve sk_live, sk- ve .env'indeki key'lerin ilk karakterlerini ara. Herhangi biri görünüyorsa, önce key'i rotate et, sonra çağrıyı sunucu tarafına taşı.
2. Doğrudan web root'undan sunulan .env veya .git
Şaşırtıcı sayıda yayındaki uygulama, sadece istersen .env dosyasını — ya da tüm .git dizinini — seve seve döndürür. Yanlış yapılandırılmış tek bir statik dosya sunucusu ya da her şeyi public klasöre kopyalayan bir framework şablonu yeterlidir.
Etki bütünseldir: veritabanı kimlik bilgileri, auth secret'ları, API key'leri, hepsi tek bir dosyada. Açıkta kalan bir .git dizini neredeyse aynı derecede kötüdür, çünkü bir saldırgan; commit'lenmiş ve sonradan "kaldırılmış" secret'lar dâhil tüm kaynak geçmişini yeniden oluşturabilir.
Hızlı kontrol on saniye sürer:
curl -i https://yourapp.com/.env
curl -i https://yourapp.com/.git/config
# Both should return 404 (or 403) — never 200.3. Content-Security-Policy yok
AI araçları neredeyse hiç güvenlik header'ı eklemez ve en çok önem taşıyanı CSP'dir. Onsuz, uygulamanın herhangi bir yerindeki tek bir HTML-injection veya XSS hatası, bir saldırganın kullanıcılarının tarayıcılarında keyfi JavaScript çalıştırmasına — oturumları çalmasına ve veri sızdırmasına — olanak tanır.
Çoğu uygulama için iyi bir başlangıç politikası: default-src 'self', object'leri ve iframe'e almayı engelle ve yalnızca gerçekten kullandığın üçüncü taraf script origin'lerine izin ver. Katı başla, bilinçli gevşet — asla tersi değil.
// next.config.js
const csp = [
"default-src 'self'",
"script-src 'self'",
"style-src 'self' 'unsafe-inline'",
"img-src 'self' data:",
"base-uri 'none'",
"frame-ancestors 'none'",
"object-src 'none'",
].join("; ");
module.exports = {
async headers() {
return [{ source: "/:path*", headers: [{ key: "Content-Security-Policy", value: csp }] }];
},
};4. Secure, HttpOnly ve SameSite olmadan oturum cookie'leri
Auth kütüphanen bir AI aracı tarafından varsayılan seçeneklerle bağlandıysa, oturum cookie'sinin flag'lerini doğrulamaya değer. HttpOnly olmayan bir cookie, enjekte edilen herhangi bir script tarafından okunabilir (küçük bir XSS'i tam hesap ele geçirmeye dönüştürür), Secure olmayan biri düz HTTP üzerinden sızabilir ve SameSite olmayan biri cross-site request forgery'yi çok kolaylaştırır.
Yayındaki uygulamanda DevTools → Application → Cookies'i aç. Her oturum ya da auth cookie'si üçünü de göstermeli: Secure, HttpOnly ve SameSite=Lax (veya Strict).
5. Asla HTTPS'e dönüşmeyen HTTP (ve HSTS yok)
Çoğu hosting platformu sana HTTPS'i otomatik verir — ama pek çok uygulama hâlâ yönlendirme yapmadan düz HTTP üzerinden seve seve yanıt verir ya da yönlendirir ama asla bir Strict-Transport-Security header'ı göndermez. Her iki durumda da, alan adını adres çubuğuna yazan bir kullanıcı ilk isteğini şifrelenmemiş yapar ve o istek, yönlendirmen gerçekleşmeden önce ele geçirilebilir ya da downgrade edilebilir.
Çözüm iki satır yapılandırmadır: HTTP'den HTTPS'e kalıcı bir 301 yönlendirmesi, artı bir HSTS header'ı (max-age=31536000; includeSubDomains) ki tarayıcılar bir daha asla downgrade yapmayı reddetsin.
6. Her şeye izin verecek şekilde ayarlanmış CORS
AI ile üretilen bir frontend, geliştirme sırasında kendi API'sine ulaşamadığında üretilen "çözüm" neredeyse her zaman Access-Control-Allow-Origin: *'tır — bazen kimlik bilgilerine de izin verilerek. Bu, internetteki her web sitesine, API'ni ziyaretçilerinin tarayıcılarından çağırabileceğini söyler.
Kendi frontend'ine hizmet eden bir API için, izin verilen origin tam olarak kendi alan adın olmalı ve başka hiçbir şey olmamalıdır. Joker CORS yalnızca gerçekten herkese açık, kimlik doğrulamasız, salt okunur API'ler için kabul edilebilir.
7. Alan adında SPF veya DMARC yok
Bu, uygulamanın koduyla hiç ilgili değil — alan adınla ilgili. SPF ve DMARC DNS kayıtları olmadan, herkes [email protected]'dan geliyormuş gibi görünen e-postalar gönderebilir ve alıcı posta sunucularının bunun sahte olduğunu anlaması mümkün değildir. Bu, markanı giyip kendi kullanıcılarına karşı yapılan phishing'dir.
İki DNS TXT kaydı bunu çözer. E-postayı Resend, Postmark ya da SES gibi bir sağlayıcı üzerinden gönderiyorsan, dokümanları sana tam SPF değerini verir; yanına bir DMARC politikası ekle ve meşru postanın geçtiğini doğruladığında onu p=none'dan p=quarantine'e sıkılaştır.
Yedisini tek seferde kontrol et
Bu listedeki her madde dışarıdan tespit edilebilir; bu da onu tek tek elle çalışmak zorunda olmadığın anlamına gelir. AppSafe tüm bu kontrolleri — artı SSL/TLS, subdomain takeover, source map'ler ve daha fazlasını — tek bir taramada çalıştırır, sonucu A–F arası notlandırır ve her bulgu için doğrudan Cursor ya da Claude Code'a geri yapıştırabileceğin bir AI düzeltme prompt'u verir.
Ana sayfadaki hızlı tarama kayıt gerektirmez. Tam tarama (açıkta kalan secret kontrolleri dâhil) yalnızca sahip olduğunu doğruladığın alan adlarında çalışır — bilinçli olarak, çünkü başkasının JS bundle'larında key aramayacağız.