Next.js Server Actions'a yerleşik CSRF kontrolleri geliyor; API route'ları ise bunu kendileri eklemek zorunda

dev.to'da yayınlanan bir yazı, Next.js güvenlik varsayılanlarındaki bir asimetriye dikkat çekiyor: Server Actions ve API route handler'ları birbirine benzeyen sunucu taraflı yapılar gibi görünse de, bunlardan yalnızca biri kutudan çıktığı haliyle cross-site request forgery'e (CSRF) karşı savunma sağlıyor.

Server Actions otomatik olarak neyi alıyor

Yazıya göre Next.js, her Server Action isteğinin Origin başlığını inceliyor ve uygulamaya ait host ile karşılaştırıyor. İkisi eşleşmediğinde, framework çağrıyı, action içindeki geliştirici tarafından yazılmış herhangi bir kod çalışmadan önce reddediyor. Yazar, bu kontrolün hiçbir yapılandırma gerektirmediğini vurguluyor; bu, uygulamanın kendi formları ve bileşenlerinden tetiklenmesi amaçlanan Server Actions tasarımından doğal olarak ortaya çıkıyor. Next.js kendi build çıktısını ve dağıtım alan adını bildiği için, same-origin kuralını dış yardıma ihtiyaç duymadan uygulayabileceği her şeye sahip.

Route handler'ları neden korumasız kalıyor

app/api/ altındaki route handler'ları esnek, genel amaçlı HTTP uç noktaları olarak tasarlandı ve bu esneklik, eşdeğer bir koruma almamalarının tam olarak nedeni. Next.js böyle bir uç noktayı kimin çağırabileceğini varsayamıyor — meşru bir şekilde bir mobil istemci, harici bir hizmetten gelen bir webhook veya uygulamanın kendi ön ucu olabilir — bu yüzden hiçbir origin doğrulaması yapmıyor.

Yazı bunun sonucunu açıkça ortaya koyuyor. Bir kullanıcı bir tarayıcı sekmesinde uygulamaya giriş yapmışsa ve başka bir sekmedeki kötü niyetli bir site, handler'ın URL'sine sessizce bir form POST'u gönderirse, tarayıcı o isteğe session cookie'yi ekler. Handler'ın bakış açısından, sahte istek, açık bir kontrol eklenmedikçe, uygulamanın kendi arayüzü tarafından yapılan meşru bir çağrıdan ayırt edilemez.

Çözüm: açık bir origin kontrolü

Yazarın önerdiği çözüm, Server Actions'ın ücretsiz aldığını yansıtıyor: Origin başlığını okuyun, uygulamanın genel URL'si gibi bir ortam değişkeninde tutulan beklenen origin ile karşılaştırın ve değerler uyuşmadığında, session veya body verilerine dokunmadan önce 403 döndürün. Her route'un buna ihtiyacı yok — hassas olmayan veri döndüren herkese açık bir GET uç noktası, isteğin nereden geldiğiyle ilgilenmez — ancak kimliği doğrulanmış bir session adına durum değiştiren her şey, tam olarak CSRF istismarlarının hedefi olduğu türdedir ve origin'ini doğrulamalıdır.

Origin kontrolü yetkilendirme değildir

Yazı iddiasını sınırlamaya özen gösteriyor. Origin doğrulaması, özellikle bir kurbanın aktif session'ını istismar eden, başka bir sitede üretilmiş sahte isteklere karşı savunma sağlar. Kimliği doğrulanmış kullanıcının, istediği işlemi gerçekten yapmaya yetkili olup olmadığı konusunda hiçbir şey söylemez. Çapraz origin'li bir isteği doğru şekilde reddeden bir Server Action, kimliği session'dan türetmek yerine istemci tarafından sağlanan bir ID'ye güveniyorsa, hâlâ bir kullanıcının başka bir kullanıcının verisini değiştirmesine izin verebilir. Origin kontrolü ve yetkilendirme ayrı katmanlardır ve birini uygulamak diğerini kapsamaz.

Neden önemli

Yazı, pratik bir denetim önerisiyle sona eriyor: Üretimde session cookie'ye dayanarak veri değiştiren API route handler'ları çalıştıran her ekip, bu uç noktaların istek origin'ini doğrulayıp doğrulamadığını ya da geçerli bir session cookie eşlik ettiği sürece herhangi bir kaynaktan gelen bir isteği kabul edip işlemeye devam edip etmeyeceğini kontrol etmeli. Daha geniş ders şu: framework güvenceleri genellikle dar bir saldırı sınıfını korur. Server Actions ve route handler'ları geliştiricilere eşit derecede sunucu taraflı görünür, ancak varsayılan güvenlik duruşları önemli ölçüde farklıdır — ve hiçbiri sizin yetkilendirme mantığını kendiniz yazma yükünü ortadan kaldırmaz.