Next.js Projelerinde Sık Karşılaşılan Güvenlik Açıkları ve Korunma Yöntemleri

Next.js, modern web uygulamaları geliştirmek için güçlü bir altyapı sunsa da; yanlış yapılandırmalar, dikkatsiz kod yazımı ve eksik güvenlik önlemleri projelerin ciddi güvenlik açıklarına maruz kalmasına neden olabilir. Bu yazıda, Next.js projelerinde sık karşılaşılan güvenlik açıklarını ve bu açıklardan korunmak için uygulanması gereken yöntemleri detaylı bir şekilde ele alacağız.

🛑 1. XSS (Cross-Site Scripting) Açıkları

XSS saldırısı, kötü niyetli bir kullanıcının web sitesine zararlı JavaScript kodları enjekte etmesine olanak tanır. Next.js, React altyapısı sayesinde XSS’e karşı görece güvenli bir yapı sunsa da bazı durumlarda açıklar ortaya çıkabilir.

💥 Riskli Senaryo:

jsxKopyalaDüzenle<div dangerouslySetInnerHTML={{ __html: userInput }} />

✅ Korunma Yöntemi:

• dangerouslySetInnerHTML kullanımı zorunlu değilse asla tercih edilmemelidir.
• HTML içerik işlenecekse DOMPurify gibi bir “sanitizer” kütüphanesiyle filtrelenmelidir.
• Kullanıcıdan alınan tüm inputlar, mümkünse sunucu tarafında doğrulanmalı ve escape edilmelidir.

🔓 2. API Endpoint’lerinin Yetkisiz Erişime Açık Olması

Next.js projelerinde /pages/api/ altında tanımlanan API rotaları, doğrudan dış dünyaya açıktır. Eğer bu endpoint’ler herhangi bir kimlik doğrulama kontrolü olmadan işlem yapıyorsa ciddi bir açıklık oluşur.

💥 Riskli Örnek:

jsKopyalaDüzenle// POST /api/delete-user?id=123
export default function handler(req, res) {
  deleteUser(req.query.id);
  res.status(200).json({ success: true });
}

✅ Korunma Yöntemi:

• JWT, session veya OAuth tabanlı kimlik doğrulama sistemleri mutlaka entegre edilmelidir.
• API içinde kullanıcının yetkisi kontrol edilmeli (örn. isAdmin, userId == req.session.user.id).
• Rate limiting ile endpoint’ler korunmalı.

📂 3. Çevresel Değişkenlerin Açığa Çıkması (env Leak)

Next.js’te .env.local dosyası, API key, veritabanı bağlantısı gibi hassas bilgileri içerir. Yanlışlıkla istemci tarafına açılan bu bilgiler projeyi tehlikeye atabilir.

💥 Riskli Örnek:

jsKopyalaDüzenleconsole.log(process.env.DB_PASSWORD); // client tarafında çalıştırılırsa risklidir

✅ Korunma Yöntemi:

• Yalnızca NEXT_PUBLIC_ prefix’i ile başlayan environment değişkenleri istemciye açılır.
• Hassas bilgileri yalnızca sunucu tarafında (getServerSideProps, API Routes) kullanın.
• .env.local dosyasını versiyon kontrol sistemine (Git) kesinlikle dahil etmeyin (.gitignore içinde olmalı).

🧨 4. Açıkta Bırakılan Dinamik Route’lar ve ID Tabanlı Erişim Açığı

Next.js projelerinde dinamik route’lar (örneğin /user/[id].js) kullanılırken, backend kontrolleri yapılmazsa kullanıcılar başkalarının verilerine ulaşabilir.

💥 Riskli Senaryo:

Bir kullanıcı /user/123 URL’ine giderek başka bir kullanıcının profiline erişebilir.

✅ Korunma Yöntemi:

• Backend tarafında mutlaka kimlik kontrolü yapılmalı. Kullanıcı sadece kendi verilerine erişebilmeli.
• Dinamik route’larda getServerSideProps ya da API route içinde req.session.user.id gibi oturum kontrolü uygulanmalı.

⚠️ 5. Açık Kaynak Paketlerden Gelen Güvenlik Açıkları

Next.js projelerinde çok sayıda NPM paketi kullanılır. Ancak bu paketler de zaman zaman güvenlik açıklarına neden olabilir.

✅ Korunma Yöntemi:

• Düzenli olarak npm audit ya da yarn audit komutlarıyla güvenlik denetimleri yapılmalı.
• Kullanılmayan bağımlılıklar silinmeli.
• Alternatif olarak snyk, dependabot gibi otomatik güvenlik araçları projeye entegre edilebilir.

🔒 6. SSR ve getServerSideProps Kullanımında Bilgi Sızdırma

SSR fonksiyonları (getServerSideProps) içinde istemciye gönderilen veriler JSON olarak döner. Yanlış yapılandırma ile sunucu tarafındaki hassas bilgiler istemciye sızabilir.

✅ Korunma Yöntemi:

• getServerSideProps içinde sadece kullanıcının görüntülemesine izin verilen bilgiler döndürülmeli.
• Özel kimlik, rol bilgisi, yetki listesi gibi veriler frontend’e gönderilmemeli.

Sonuç: Küçük Hatalar Büyük Açıklara Neden Olabilir

Next.js güçlü ve esnek bir framework olsa da; güvenlik açıkları geliştirici farkındalığına bağlı olarak ortaya çıkabilir. Bu nedenle:

• Güvenli kod yazımı alışkanlık haline getirilmeli,
• Kod gözden geçirme (code review) süreçleri uygulanmalı,
• Güvenlik testleri ve taramaları düzenli olarak yapılmalıdır.

Her zaman unutulmamalıdır: Güvenlik bir özellik değil, bir süreçtir.