Eksik Bir Config Satırı, Bir Hastane Eczanesi Uygulamasının Girişini Opsiyonel Yaptı

Ablam bir hastanede kemoterapi eczanesi işletiyor, ilaç stoğuyla döküm kayıtlarını tek yerden takip edecek bir yazılıma ihtiyacı vardı — denetimde sorun çıkarmayacak kadar sağlam bir muhasebe. Kod yazmayı bilmiyor, o yüzden ilk versiyonu AI ile hazırladı. Ben de işi “kendi bilgisayarımda çalışıyor” seviyesinden “hastane ağının önüne güvenle koyabilirim” seviyesine taşıdım, sıkılaştırdım, deploy ettim. Bu süreçte yazmaya değer bir bug çıktı ortaya — AI’ın ürettiği koda özgü değil, deneyimli geliştiricileri de yakalayan bir Cloudflare Workers tuzağı.

Kurulum nasıldı #

Uygulama küçük bir Cloudflare Worker: public/ altından servis edilen statik HTML/JS, auth’u ve stok/döküm API’sini yöneten bir worker.js, veritabanı olarak D1. Cloudflare’in ücretsiz katmanında ucuza ve hızlıca ayağa kaldıracağınız her şey için standart bir kurulum.

Auth kağıt üzerinde sorunsuzdu: giriş sayfası, D1’de tutulan session token’ları, HttpOnly/Secure/SameSite cookie’ler, rate-limitli giriş denemeleri. Worker, herhangi bir korumalı veriyi döndürmeden önce geçerli bir session arıyordu. İstediğiniz her parça oradaydı.

Bug neydi #

Hiçbirinin önemi yoktu, çünkü korumalı sayfa Worker’a hiç uğramıyordu.

Cloudflare Workers’ta Static Assets bir isteği iki şekilde yönlendirebiliyor: platform eşleşen statik dosyayı doğrudan edge’den servis eder, ya da önce Worker’ı çalıştırıp neyin servis edileceğine ona karar verdirir. Varsayılan davranış birincisi. İkincisini açıkça seçmediğiniz sürece Cloudflare index.html‘i — ya da başka herhangi bir statik dosyayı — doğrudan cache’ten döner, Worker’ınızdaki auth kontrolü hiç çalışmaz.

Düzeltmesi wrangler.toml‘da tek satır:

[assets]
directory        = "./public"
binding          = "ASSETS"
run_worker_first = true

run_worker_first = true yoksa, statik dosya olarak servis edilen her şey — API çağrısı yerine statik dosyaymış gibi sunulan gerçek stok/döküm verisi dahil — auth’u tamamen atlıyordu. URL’i bilen (ya da tahmin eden) herkes sayfayı görebiliyordu. Auth mantığı yanlış olduğundan değil, hiç çalışmadığından.

Kodu siz yazmasanız da bunun önemi #

Bu bir “AI kötü kod yazdı” hikayesi değil. Session yönetimi, parola hashleme (PBKDF2-SHA256, 100 bin iterasyon), rate limiting — hepsi yerli yerindeydi. Bug bir üst katmanda, uygulama mantığıyla alakası olmayan, tamamen Workers + Static Assets’in bir isteğe kimin önce bakacağına karar veren platform routing config’inde saklanıyordu. Kusursuz bir auth middleware yazıp yine de o middleware’in devre dışı kaldığı bir uygulamayı deploy edebilirsiniz.

Genel kural şu: auth’unuz bir Worker’da, içeriğiniz aynı platformda statik asset olarak duruyorsa, platformun varsayılan routing’i her isteği önce Worker’a mı uğratıyor, yoksa sadece statik dosyayla eşleşmeyenleri mi — bunu kontrol edin. En doğrusu doğrudan test etmek: session cookie’si olmadan korumalı bir route’a istek atın, geri çevrildiğinizi gözünüzle görün.

Aynı sıkılaştırma sürecinden iki küçük not daha:

• D1’in satır/kolon boyutunda bir üst sınırı var. Uygulama tüm state’i tek bir JSON blob’da tutuyordu; belli bir boyutu geçince kayıtlar storage katmanında sessizce başarısız olmaya başladı. Çözüm, yazmadan önce blob’u sıkıştırmaktı. D1’e blob benzeri bir şey yazıyorsanız, o sınırı üretimde çarpmadan önce öğrenin.
• Response.redirect() Workers’ta mutlak URL istiyor — göreceli bir path verirseniz redirect yerine runtime’da hata fırlatıyor. Local’de test isteğiniz zaten doğru base URL’i taşıdığından bu fark edilmeden geçebiliyor.

Kısacası #

• Cloudflare Workers + Static Assets, varsayılan olarak eşleşen dosyayı doğrudan servis eder — Worker’ınız (ve içindeki auth) run_worker_first = true demediğiniz sürece devreye girmez.
• “Auth kodu doğru” ile “auth kodu her zaman çalışıyor” iki farklı şey. İkincisini, sadece Worker’ın içine bakarak değil, gerçek routing’i test ederek doğrulayın.
• AI’ın yazdığı uygulama mantığını doğruluk açısından inceleyin, ama orada durmayın — auth’un sessizce devre dışı kaldığı yer platform config’i, ve bunu sadece Worker dosyasını okuyarak yakalayamazsınız.

Yan iş olarak web uygulaması sızma testleri yapıyorum — auth mantığı, erişim kontrolü, ve bunun gibi Cloudflare Workers’a özgü tuzaklar dahil OWASP top 10’un geri kalanı. Girişin arkasında gerçek veri barındıran bir şey deploy ediyorsanız, ikinci bir göze ihtiyacınız varsa: [email protected].