Next.js 16 ile Üç Maliyetli Auth Hatası Yaptım
Üç farklı projede proxy.ts matcher kısmını berbat ettim.
En kötü yanı ne mi? Hiçbir hata yoktu. Uyarı yok. Log yok. Güvenlik açıkları ortaya çıkana kadar her şey mükemmel görünüyordu.
Next.js 16, middleware.ts dosyasını proxy.ts olarak değiştirdi. Bu sadece bir isim değişikliği değil; istekleri işleme biçiminizde temel bir değişim.
Auth yapınızı bozmamak için bilmeniz gerekenler şunlar:
Yeni Kurallar Middleware kafa karıştırıcıydı. Geliştiriciler onu veritabanı çağrıları ve ağır mantıksal işlemler için kullanıyordu. Bu onun görevi değil.
Proxy, ağ sınırında yer alır. İstekleri rotalarınıza ulaşmadan önce yakalar.
- Varsayılan olarak Edge runtime üzerinde değil, Node.js üzerinde çalışır.
- Tam crypto desteği alırsınız.
- Herhangi bir standart JWT kütüphanesini ek çözümlere (workaround) ihtiyaç duymadan kullanabilirsiniz.
Sessiz Başarısızlık Eğer bir codemod kullanmadan Next.js sürümünü yükseltirseniz, eski middleware.ts dosyanız projenizde kalabilir. TypeScript kontrollerinden geçer. Sorunsuz bir şekilde derlenir.
Ancak hiçbir şey yapmaz.
Yönlendirmeleriniz çalışmaz. Auth işleminiz yürütülmez. Uygulamanız güvenlik katmanını sessizce atlar.
Şu Üç Şeyi Manuel Olarak Kontrol Edin:
- proxy.ts dosyasının proje kök dizininde olduğundan emin olun.
- Dışa aktarılan (exported) fonksiyonun adının middleware değil, proxy olduğundan emin olun.
- Eski middleware.ts dosyasını tamamen silin.
Matcher Tuzağı Çoğu auth kurulumu matcher konfigürasyonunda bozulur. Eğer statik dosyaları hariç tutmazsanız, proxy her CSS ve JS dosyası için çalışır. Bu da varlıklar (assets) üzerinde sonsuz yönlendirme döngülerine neden olur.
Şunları hariç tutmak için bir negative lookahead kullanın:
- _next/static
- _next/image
- favicons ve sitemaps
- resim uzantıları (png, jpg, svg)
Uyarı: Sadece Header'lara Güvenmeyin Canımın yandığı yer burasıydı.
Proxy, istek üzerinde x-user-id gibi header'lar ayarlar. Server Component'leriniz bunları headers() aracılığıyla okur.
Eğer matcher kısmında bir boşluk varsa, bir kullanıcı kendi x-user-id header'ını gönderebilir. Server Component, proxy tarafından ayarlanan bir header ile istemci tarafından gönderilen bir header arasındaki farkı anlayamaz.
Bir saldırgan, eşleşmeyen bir rota üzerinde bir kullanıcı kimliğini (user ID) taklit edebilir (spoof). Verileri göremeyebilirler ancak sahip olmamaları gereken yetkileri elde edebilirler.
Çözüm: Proxy, sizin hızlı kapınızdır. Ağın sınırında (edge) ağır işleri halleder.
Ancak JWT'yi Server Component'lerinizin içinde tekrar doğrulamanız gerekir.
- Proxy, çoğu kötü niyetli aktörü hızlıca durdurur.
- Matcher başarısız olursa, Server Component kontrolü boşluğu kapatır.
Yedeklilik güvenliktir.