Cloudflare’ın yapay zekayla yazılan OAuth kütüphanesine yakından bakış

• Cloudflare, Anthropic’in Claude LLM modelini kullanarak yeni bir OAuth kütüphanesi geliştirdi ve kullanılan prompt’ları da birlikte yayımladı
• Kütüphanenin kod yapısı temiz olsa da test ve güvenlik doğrulaması açısından önemli eksikler bulunuyor
• CORS ve bazı kimlik doğrulama standardı uygulamalarında standart dışı veya riskli tercihler tespit edildi
• Kriptografi uygulamasında güçlü yönler olsa da ciddi güvenlik hataları ve protokol yanlış anlamaları ortaya çıktı
• LLM tabanlı otomatik kodlama faydalı olsa da üretim seviyesinde güvenlik için uzmanların titiz incelemesi şart

---

Cloudflare OAuth kütüphanesine genel bakış

• Cloudflare, OAuth sağlayıcı kütüphanesini büyük ölçüde Anthropic’in Claude LLM modelini kullanarak otomatik yazdı
• Claude’un çıktıları, deneyimli Cloudflare mühendislerinin güvenlik ve standart uyumluluğu incelemesinden geçti; commit geçmişinde de yapay zekayla etkileşim süreci şeffaf biçimde paylaşıldı
• İlk uygulamanın ardından Claude’a verilen ek prompt’lar ve sonuçların gözden geçirilmesiyle kalite iyileştirildi
• Sadece yapay zekaya dayanılmadığı, RFC belgeleriyle çapraz kontrol ve alan uzmanı incelemesinin özellikle vurgulandığı belirtildi

Uzmanın ilk izlenimi ve kod analizi

• LLM ile kod yazımına özgü biçimde kod tek bir dosyada yoğunlaşmış olsa da yapı tutarlı ve gereksiz yorum sayısı görece az
• İşlevsel testler mevcut ancak OAuth gibi kritik bir kimlik doğrulama hizmeti için gereken seviyeye ulaşmıyor
  • Zorunlu (MUST/MUST NOT) şartname kontrollerinin eksik olduğu ve parametre doğrulamasının zayıf kaldığı görülüyor

Güvenlik endişeleri ve çevirmen açıklaması

1. CORS politikası sorunu ("YOLO CORS")

• Neredeyse tüm origin’lere izin veren ve same-origin politikasını fiilen devre dışı bırakan CORS başlık ayarları tespit edildi
• Bu bölüm, Cloudflare mühendisi tarafından LLM değil, doğrudan insan kararıyla belirlenmiş
• credentials özelliği etkin olmadığı için yıkıcı tarayıcı güvenlik riski sınırlı, ancak neden ve amaç yeterince net değil

2. Standart güvenlik başlıklarının uygulanmaması

• HTTP yanıtlarında X-Content-Type-Options: nosniff ve HTTP Strict Transport Security gibi temel güvenlik başlıklarının uygulanmadığı görülüyor
• JSON API yapısı nedeniyle bazı başlıkların gerekliliği daha düşük olabilir, ancak istemci/tarayıcı zafiyetlerini önlemek açısından bunların eklenmesi önemli

3. OAuth standardına dair yetersiz hakimiyet izleri

• Public client desteği için, OAuth 2.1’de kaldırılmış olan implicit grant yöntemi uygulanmış
  • Oysa bu özellik PKCE veya CORS gevşetmesiyle yeterince ikame edilebilir
  • Görünüşe göre Claude implicit grant’i önermiş, ancak gerçek token verme aşamasında bunu doğru biçimde doğrulamıyor
• Basic Auth işleme eksikliği: OAuth’ta gereken kendine özgü URL encoding biçimi atlanmış
  • Bu durum, istemci sırrında iki nokta üst üste bulunması halinde ortaya çıkabilecek bir güvenlik hatasına yol açan ikincil bir sorun
  • Ancak bu kütüphane istemci kimliği/sırrını kendi ürettiği için biçim üzerinde denetim kurabiliyor

4. Token ID üretim kodundaki güvenlik sorunu

• Token ID için rastgele dize üretme yöntemi istatistiksel yanlılık (biased) içeriyor
  • Entropi azalması saldırıyı kolaylaştırabilir, ancak pratikteki tehdit sınırlı görünüyor
• "Tüm kod satırları uzmanlar tarafından incelendi" iddiasına rağmen, ilk commit’te hata olduğu gibi duruyor
  • İlk gün tek bir geliştiricinin ana dala 21 kez doğrudan commit atmış olması gibi kayıtlar, sistematik inceleme eksikliğine işaret ediyor

Kriptografi özellikleri ve LLM etkileşimi örnekleri

• Token deposu şifreleme tasarımı insan tarafından yönlendirildi, uygulamada ise Claude destek verdi
• Her token için props şifreleniyor ve her token için simetrik anahtar sarmalanıyor
• Claude süreç içinde hatalı bir tasarım önerince mühendis, niyeti ve güvenlik gerekçesini açıkça ortaya koyarak bunu düzeltti
  • Örnek: SHA-256 hash’ini wrapping key olarak kullanmanın doğuracağı zafiyet işaret edilince HMAC tabanlı yapıya geçildi
  • PBKDF2 önerisi için performans verimsizliği vurgulandı ve 32 baytlık HMAC anahtarı kullanımına geçildi
• Bu süreç, yapay zekayla çalışırken yüksek düzeyde alan bilgisine ihtiyaç duyulduğunu açıkça gösteriyor
  • Ölümcül kusurlar, uzman olmayan biri tarafından fark bile edilemeyebilir

Genel değerlendirme ve çıkarımlar

• İlk sürüm olmasına rağmen genel kalite makul, ancak doğrudan canlı hizmette kullanmak için riskli
• OAuth sağlayıcısı geliştirmek, doğası gereği çok zorlu güvenlik ve işlev doğrulaması gerektiriyor
  • Büyük şirketlerde yüz binlerce otomatik test ve çok katmanlı güvenlik denetimi olağan kabul ediliyor
  • Bu, LLM tabanlı otomatik kodlamanın “kolayca” uygulanabileceği bir alan değil
• Projenin commit geçmişi, LLM’lerin ne seviyeye kadar yardımcı rol oynayabildiğini ilgi çekici biçimde gösteriyor
  • Ancak bazı kusurlar hem LLM’lerin hem de insanların sık yaptığı hatalar arasında; benzerleri Stack Overflow yanıtları gibi mevcut topluluk içeriklerinde de görülebiliyor
  • Titizlik ve dikkat gerektiren kod alanlarında hem yapay zekanın hem de insanın çok dikkatli olması gerekiyor
• LLM ile kod incelemek veya sonuçlara güvenmek için doğrudan uygulama deneyimi ve System 2 düşünme şart
  • Basit veya çekirdek olmayan işlerde LLM’lere rahatça görev verilebilir, ancak kimlik doğrulama ya da güvenlikle ilgili temel sistemlerde tasarım ve uygulamanın uzmanlarca yürütülmesi daha uygun

[xguru]

Cloudflare’ın Claude ile OAuth geliştirip tüm prompt’ları herkese açık etmesine bir göz atış

[GN⁺]

Hacker News görüşü

• Bu örnek, LLM'lerle etkileşim kurarken ciddi miktarda alan bilgisine ihtiyaç olduğunu doğrudan gösteriyor. Örneğin Claude'un arada uydurduğu “kritik kusur”u sıradan bir geliştirici fark etmeyebilirdi. PBKDF2'ye geçişi garip bulmak da alan uzmanlığı sayesinde mümkün. Benim vardığım sonuç şu: LLM'leri verimli kullanmak için yetkin bir gözden geçiren ve bir “lider” gerekli. Eğer ilgili konuda LLM kadar bile bilgi sahibi değilseniz, mutlaka düşük önem seviyeli işlerde kullanmalı ya da tüm çıktıları doğrulayabilecek kadar bol zamana sahip olmalısınız

  • Bundan sonra bu yeni ortamda alan uzmanlarının nereden çıkacağı da merak uyandırıyor. Sonuçta bu kadar derin bilgiye kim sahip olacak diye düşünüyorum

  • İnsanların “LLM'leri sadece iyi bilmediğin alanlarda kullanırsın, uzmansan kodu kendin yazarsın” dediğini her duyduğumda şaşırıyorum. Tam tersine, uzmanlar LLM çıktısını çok daha doğru değerlendirebilir ve ben ne istediğimi alan uzmanına özgü bir şekilde ne kadar iyi anlatırsam sonuç da o kadar iyi oluyor. Bir bakıma bu çok doğal (çünkü LLM istatistiksel olarak üretilmiş bir metin motoru)

  • LLM'ler varsayılan değer ekleme, istisna işleme ve türlü türlü dolambaçlı yolları fazla kolay ekleme eğiliminde. Bu yüzden çalışıyor gibi görünen ama aslında sorunlu olan ya da yakında patlayacak kodlar kolayca ortaya çıkıyor. Yazdığım CLAUDE.md içinde bunu birkaç kez özellikle vurgulamaya çalışmış olmama rağmen sık sık yine aynı tür sonuçlar geliyor

  • Ben LLM ile k8s dağıtım işlerinin çoğunu hallettim. Hızlıca çalışan sonuçlar üretiyor ama sürekli secret kullanmasını ve kimlik bilgilerini düz metin olarak commit etmemesini hatırlatmak zorunda kaldım. Bu tip hatalar gerçekten tehlikeli. Eğitim amaçlı tutorial'lar genelde temele odaklanmak için güvenliği sık sık atlıyor; LLM eğitim verisinde de bu örnekler çok fazla olduğu için çıktının böyle geldiğini düşünüyorum

  • Zamanla AI kodlama araçlarının alan bilgisini kendilerinin araştırabileceğini umuyorum. Şimdiden çıkan bazı “AI araştırma” araçları bu konuda çok güçlü ama henüz kodlama araçlarıyla düzgün entegre değiller. Araştırma yalnızca açık interneti değil, şirket içi dokümanlardaki alan bilgisini de referans alabilir. Tabii bazı bilgiler sadece insanların kafasının içinde olduğundan, bunları kullanıcının bizzat aktarması gerekecek

• Yakın zamanda AI yardımıyla bir Kafka consumer yazarak veri migrasyonu yaptım. Bu, kısa ömürlü, sıfırdan başlayan bir proje olduğu ve ben dili (go) epey bilsem de uzun süredir kullanmadığım için AI'dan alınan verimin zirve yaptığı türden bir durumdu. Tüm veriler tek bir topic'e geldiğinden performans için oldukça karmaşık paralel işleme kurdum. Genel olarak AI sayesinde yaklaşık 2 kat hızlandığımı hissettim. Özellikle go sözdizimini ara sıra unuttuğumda arama yapmak yerine AI'ya doğrudan sormak çok yardımcı oldu. Ama içinde en az 4 potansiyel bug gizliydi (bunun dışında bariz bug'lar çok daha fazlaydı). Kafka'ya ya da multithreading'e aşina olmasaydım muhtemelen bunu doğrudan production'a çıkarmış olurdum. Büyük/uzun vadeli projelerde iyileşme daha çok %10–20 seviyesinde oluyor. Güncel modellerle görünen eğilim bu. Genel olarak bakınca bu, bellek yöneten dillere geçince elde ettiğimiz üretkenlik artışına benziyor. PM'lerin geliştiricilerin yerini alacağı hayaline hiç benzemiyor (son 3 yıldaki değişim hızına bakarsak). Asıl endişem şu: orta seviye, “teknik fırtına” sınıfı geliştiriciler AI ile 10 kat verimli hale gelirse, ince bug'ları bulamayıp yönetemedikleri için daha tehlikeli olabilirler. Kıdemli/staff mühendisler de review selini kaldıramayabilir. Ayrıca junior'dan senior'a büyüme süreci daha da kırılgan hale gelir mi diye kaygılanıyorum. Kopyala-yapıştır programcı zaten başlı başına bir sorundu; AI bunu daha da güçlendiriyor. Sonunda piyasada bir denge oluşur ama bunun on yıllar alabileceği düşüncesi huzursuz ediyor

  • AI'ın ürettiği bug'lar gerçekten sinsi. Ben de AI'ya multithread kod yazdırıp ince bir bug'ı gerçekten production'a almıştım. Review ve test yapsanız bile, kodu elle yazdığınız zamanki kadar yoğun bir dikkat oluşmuyor. Bir süre daha AI'ın yazdığı kodu kullanırken sık görülen bug kalıplarını önceden kontrol etmek ve bunu kritik etkisi olmayan alanlarla sınırlamak gerektiğini hissediyorum

  • Ben de “önemli işler” için ancak %10–20 civarında iyileşme hissediyorum. Gerçek bir değişim bu ama yazılım geliştirmenin özünü değiştirmiyor. Sonuçta Brooks'un "No Silver Bullet" tezinin yeniden doğrulanması gibi

  • Ben de "orta seviye teknik fırtına" argümanına katılıyorum. Özellikle danışmanlık sektöründe veteranlar çoğu zaman maliyetine göre düşük değerli görülüyor. Eskiden ben de hızlı teslim eden taraftaydım ve sonra teknik olmayan PM'lere kısa vadeli çözümlerin zayıf yanlarını anlatmakta zorlandığım oldu. Büyük teknoloji şirketleri bu sorunları hızlı yakalar ama gerçekte finans ve sağlık verisiyle çalışan kodlar ucuz kısa süreli sözleşmeli çalışanlara yazdırılıyor. Bu durum LLM'lerden önce de sorundu. Şimdi ise güvenliğe duyarlı geliştiriciler için çok daha zor bir dönem olabilir

  • Üretilen kodda ince bug'lar bulduğunu söyledin; peki bu bug'ları AI'ın ürettiği test koduyla otomatik tespit etmek nasıl olur diye düşünüyorum. Elbette test kodunun kendisinde de bug olabilir ama gelecekte, üretilen koddan çok test sonuçlarını yoğun biçimde incelediğimiz bir senaryo gözümde canlanıyor

  • Karmaşık paralel işleme demişsin ama bu, partition ve consumer-group kullanımıyla çözülebilecek bir alan değil mi diye merak ediyorum

• LLM'lere aşırı güvenip adeta “uçurumdan atlar gibi” eleştirel düşünmeden yaslanarak çalışan insanları görmek beni çok bunaltıyor. Tam bir kara kutuya bağımlı şekilde çalışıp doğrulamayı da ona bırakmak tehlikeli. Üstelik muazzam enerji tüketen bir yapı bu ve insanı ikame etmenin bahanesi olarak da kullanılabiliyor. Bunun hayatı 10 kat daha iyi hale getirdiğine açıkçası inanmıyorum

• Bir şeyi bizzat geliştirmekle başkasının ürettiği bir çıktıyı (özellikle LLM kaynaklı kodu) doğrulamak arasında karşılaştırma yaptığınızda, insanlar çoğu zaman inandırıcı görünen dış yüzeye aldanıp kusurları daha az eleştirel kabul etme eğiliminde oluyor. Kodun “görünüşü” bile bug bulmayı ciddi biçimde etkiliyor. Bunu doğrulamak için koda bilerek bug yerleştirip review yapanların bunları bulup bulmadığını deneyebilirsiniz. Bir şeyi kendi elinizle yazınca çok daha yavaş ve titiz düşünür, ayrıntılara dikkat edersiniz (ve bu sayede beklenmedik bug'ları da bulursunuz). Bu yüzden öğrenme amacıyla araçların “oyuncak sürümünü” bizzat yazmanın en iyi yöntem olduğu sık sık önerilir. Bu, insanın bilişsel yapısıyla ilgili bir konu

  • Yüzeyde temiz görünen kodda ince bug'ları yakalama yeteneği, çok sayıda review deneyiminden doğan bir sinizm ve şüphecilikten geliyor. Ben de uzun süre review'a vakit ayırdığım için artık ne tür kod olursa olsun potansiyel sorunları varsayıyorum. Kendi yazdığım kod olsaydı bug sayısı daha az olur muydu bilmiyorum ama ben de kendi yazdığım kodda aptalca hatalar yaptığım için buna garanti veremem. Hatta muhtemelen bu kütüphaneyi kendim bile kullanmazdım (yapacak çok iş olduğu için genelde junior mühendislere devrediliyor). Sonuç olarak insanların yazdığı kodda da bug'lar ortadan kalkmıyor, bundan eminim. Hatta Claude'un ürettiği bug'ların çoğu, bir insanın rahatlıkla yapabileceği kadar tipik hatalar. Öte yandan şu anda Cloudflare'da LLM yüzünden geliştiricilerin yerinin alınacağını sanmıyorum. Daha fazla insan işe almak yapılacak iş miktarından çok bütçeye bağlı. LLM sayesinde üretkenlik artarsa gelir de artabilir ve bu da daha çok kişiyi işe alma akışını doğurabilir. (Tabii bu, şirketin resmi görüşü değil; benim kişisel fikrim)

• Yazıda gereksiz yorumların çok olmadığı söylenmişti ama gerçek kodda // Get the Origin header from the request gibi anlamsız yorumlar var

  • Bu tür yorumlar LLM kullanıldığının belli ettiği işaretler; hiçbir anlam taşımadıkları için hep siliyorum

  • İnsanlar için bu yorumlar işe yaramaz ama LLM açısından, alttaki kodun işlevinin doğal dille de yazılmış olması anlamaya yardımcı olan bir tür Rosetta taşı görevi görebilir diye tahmin ediyorum. Bunun bedeli daha fazla token harcamak olabilir ama gerçekten de LLM'lerin aşırı yorumlu kodlarda daha iyi düzenleme yapıp yapmadığını test etmek isterdim

  • Claude'un bu tür faydasız ve tekrar eden yorumları inanılmaz sık yazdığına dair deneyim paylaşımı

• Bence ilginç bir deney, kodun bir branch'ini dondurup AI'ları kullanarak bir tarafın zafiyet üretip gizlemeye çalıştığı, diğer tarafın da bunları bulup düzelttiği bir battle kurmak olurdu. Yani satrançtaki evrim sürecini kod geliştirmeye uygulamak gibi

• Ben tam da bu kütüphanenin yazarıyım (daha doğrusu prompt yazarı). Neil kadar olmasa da OAuth konusunda belirli bir uzmanlığım var ve onun kod review yapmış olmasına gerçekten sevindim. “YOLO CORS” konusunda bir yanlış anlaşılma vardı; bu, basit bir acemilik hatası değildi. Bu CORS ayarları dikkatle düşünülerek kasıtlı şekilde yapıldı. CORS yalnızca OAuth API (token exchange, client registration) endpoint'lerinde ve OAuth bearer token gerektiren API endpoint'lerinde devre dışı bırakıldı. Bu endpoint'ler tarayıcı kimlik bilgileriyle (cookie vb.) doğrulanmadığı için, aslında CORS'un koruduğu hiçbir şey olmadığını düşünüyorum. CORS'un özü, kimlik bilgilerinin otomatik eklenmesini engelleyen bir güvenlik katmanı olması; bearer token ise istemci tarafından açıkça eklenmek zorunda olduğundan cross-origin durumlarda da güvenli. Hatta geçmişte CORS spesifikasyonunun yazarlarıyla bu konuda tartışmışlığım var; tarayıcı kimlik bilgileri yerine bearer token kullanılmasının gerçekten daha güvenli olduğunu savunuyordum. Öte yandan token ID üretiminin verimsiz olduğu eleştirisine gelince, bunu “kritik” seviyede görmüyorum. Güvenliğin kendisinde bir sorun yok ve algoritma daha sonra serbestçe değiştirilebilir. Tek bir kişi tarafından bir günde main'e 21 commit çıkmış gibi görünmesinin sebebi, Git geçmişinin yeniden yazılması yüzünden GitHub'da tarihin çarpık görünmesi. Kriptografi uygulamasına dair övgü için gerçekten teşekkürler. Bu AI'ın üretimi değildi; benim açık tasarım talimatlarım vardı

  • “OAuth API'de CORS header'larını devre dışı bırakıyoruz” dendi ama gerçekte yapılan şey, CORS kurallarını etkisiz kılacak şekilde CORS header'ları ayarlamak. Bağlamdan anlaşılıyor ama kafa karıştırıcı olabileceği için ek açıklama yapmak istedim

  • Cloudflare'ın bu kütüphaneyi gerçekten production'da kullanma planı olup olmadığını merak ediyorum

• Popüler Stack Overflow yanıtlarında da aynı hatalar çokça var ve Claude'un da oralardan öğrenmiş olabileceğini düşününce kaygılanıyorum. Asıl korkutucu olan, güvenlik açıklarının ya da hataların kendisinden çok, toplumun bilgi havuzunun LLM öncesi internetin popüler cevaplarında donup kalabilmesi

  • Ben de aynı şekilde kaygılanıyorum. Kullandığım bazı servisler “kod yazarken LLM kullanmıyoruz” diye bunu açıkça belirtse, bu benim için büyük bir güven unsuru olurdu

• ForgeRock'ta OAuth uygulamasında yüzlerce güvenlik bug'ı vardı; yüz binlerce otomatik test, tehdit modelleme, en üst düzey SAST/DAST ve uzman review'ları yapılmasına rağmen sonuç böyleydi. Bu da OAuth'un ne kadar zor olduğunu yeniden hissettiriyor. Hatta bazıları buna “çöp yangını” gibi bir implementasyon diyor. Ben şahsen ne spesifikasyonu okudum ne de uyguladım

  • OAuth implementasyonuna dahil olduğum her seferinde korkunç derecede karmaşık olduğunu hissettim

  • OAuth gerçekten çok can sıkıcı ve çok fazla niş durum var

  • Aslında yeni yazılmış kodun her zaman bug'lı olması beklenir. Karmaşıklık arttıkça bu daha da kesinleşir. Şirketlerin “battle tested” yani sahada doğrulanmış kod ve araçlara yönelmesinin nedeni de bu. Şaka bir yana, Anthropic'in kendi üretici AI'ını kendi kodunda pratik biçimde nasıl kullandığı ilginç. Acaba ileride MCP auth API için de kullanırlar mı diye merak ediyorum

  • “Yüz binlerce test” ifadesi kulağa ya sadece nicel büyüme gibi geliyor ya da doğrudan LLM üretimi olabilir diye düşündürüyor. Gerçekte bunları kimin yönettiğini de merak ediyorum

• İnsanların kendi prompt'larını Git'e commit etme eğiliminin yaygınlaşıp yaygınlaşmayacağını, yoksa bunun sadece bir tür gösteri mi olduğunu merak ediyorum

  • Prompt'u commit etme nedenim, LLM'in böyle bir prompt ile nasıl bir çıktı ürettiğini doğrudan görmenin inanılmaz öğretici olmasıydı. Başkalarının da bunu ilginç bulacağını düşündüm ve gerçekten öyle oldu. Bu arada, ben de prompt'u “iyi” yazmanın yolunu bilmiyordum; sadece bir insana yazarmış gibi doğal biçimde yazdım ve iyi çalıştı gibi göründü