- Cloudflare mengembangkan pustaka OAuth baru dengan memanfaatkan Claude LLM dari Anthropic, dan juga mempublikasikan prompt-nya
- Struktur kode pustaka ini rapi, tetapi masih banyak kekurangan dari sisi pengujian dan verifikasi keamanan
- Dalam CORS dan implementasi sebagian spesifikasi autentikasi, ditemukan pilihan yang tidak standar atau berisiko
- Implementasi kriptografinya punya kelebihan, tetapi juga memperlihatkan bug keamanan serius dan kesalahpahaman terhadap protokol
- Auto-coding berbasis LLM memang membantu, tetapi untuk keamanan tingkat produksi, tinjauan mendalam dari ahli tetap mutlak diperlukan
Gambaran umum pustaka OAuth Cloudflare
- Cloudflare menulis sebagian besar pustaka OAuth provider ini secara otomatis dengan memanfaatkan Claude LLM dari Anthropic
- Hasil keluaran Claude ditinjau oleh engineer Cloudflare yang berpengalaman untuk keamanan dan kepatuhan standar, dan proses interaksi dengan AI dipublikasikan secara transparan melalui riwayat commit
- Setelah implementasi awal, kualitasnya disempurnakan lagi lewat prompt tambahan untuk Claude dan peninjauan hasilnya
- Cloudflare juga menegaskan bahwa mereka tidak hanya mengandalkan AI, melainkan menekankan pemeriksaan silang dengan dokumen RFC serta review dari ahli inti
Kesan awal pakar dan analisis kode
- Sesuai ciri khas gaya coding dengan LLM, kode terkonsentrasi dalam satu file, tetapi strukturnya konsisten dan relatif minim komentar yang tidak perlu
- Pengujian fungsional memang ada, tetapi belum mencapai tingkat yang dibutuhkan untuk layanan autentikasi penting seperti OAuth
- Terlihat ada bagian pemeriksaan spesifikasi wajib (MUST/MUST NOT) yang hilang serta validasi parameter yang lemah
Kekhawatiran keamanan dan penjelasan penerjemah
1. Masalah kebijakan CORS ("YOLO CORS")
- Ditemukan pengaturan header CORS yang mengizinkan hampir semua origin, sehingga same-origin policy pada praktiknya nyaris dinonaktifkan
- Bagian ini diputuskan langsung oleh engineer Cloudflare, bukan oleh LLM
- Karena fitur credentials tidak diaktifkan, ancaman keamanan browser yang fatal memang lebih rendah, tetapi kejelasan alasan dan tujuannya masih kurang
2. Header keamanan standar tidak diterapkan
- Pada respons HTTP, terlihat tidak diterapkannya header keamanan penting seperti X-Content-Type-Options: nosniff dan HTTP Strict Transport Security
- Karena sifatnya JSON API, sebagian header mungkin terasa kurang penting, tetapi penerapannya tetap sangat diperlukan untuk mencegah kerentanan pada klien/browser
3. Jejak kurang paham terhadap standar OAuth
- Untuk mendukung public client, pustaka ini mengimplementasikan implicit grant yang sudah dihapus di OAuth 2.1
- Padahal fungsi tersebut sebenarnya cukup bisa digantikan dengan PKCE atau pelonggaran CORS
- Tampaknya Claude merekomendasikan implicit grant, dan pada tahap penerbitan token pun validasinya tidak dilakukan dengan benar
- Penanganan Basic Auth kurang memadai: di OAuth dibutuhkan skema URL encoding yang khas, tetapi ini tidak diterapkan
- Ini menjadi secondary issue berupa bug keamanan yang bisa muncul bila client secret mengandung tanda titik dua
- Namun, pustaka ini secara internal membuat client ID/secret sendiri, sehingga formatnya dapat dikendalikan
4. Masalah keamanan pada kode pembuat token ID
- Metode pembangkitan string acak untuk token ID memiliki bias statistik
- Penurunan entropi ini bisa mempermudah serangan, meski ancaman praktisnya terbatas
- Bertentangan dengan klaim bahwa setiap baris kode telah ditinjau ahli, bug tersebut tetap ada apa adanya di commit awal
- Riwayat seperti satu developer yang melakukan 21 commit langsung ke branch utama pada hari pertama mengisyaratkan kurangnya review yang sistematis
Fitur kriptografi dan contoh interaksi dengan LLM
- Rancangan enkripsi penyimpanan token dipimpin oleh manusia, sementara implementasinya dibantu Claude
- Properti tiap token dienkripsi, dan untuk setiap token digunakan pendekatan pembungkusan kunci simetris
- Ketika Claude sempat mengusulkan rancangan yang keliru, engineer menjelaskan maksud dan tujuan keamanannya dengan jelas agar bisa diperbaiki
- Contoh: setelah menunjukkan kerentanan yang muncul bila hash SHA-256 dipakai sebagai wrapping key, desainnya diubah ke pendekatan berbasis HMAC
- Untuk usulan PBKDF2, engineer menyoroti inefisiensi performanya lalu menyesuaikannya menjadi penggunaan kunci HMAC 32-byte
- Proses ini dengan jelas menunjukkan perlunya pengetahuan domain tingkat tinggi saat bekerja dengan AI
- Cacat fatal semacam ini bahkan bisa tidak disadari sama sekali oleh non-ahli
Penilaian akhir dan implikasi
- Meski ini versi pertama, tingkat kematangannya cukup layak, tetapi masih terlalu berisiko untuk langsung diterapkan pada layanan nyata
- Pengembangan OAuth provider pada dasarnya memerlukan verifikasi keamanan dan fungsional yang sangat sulit
- Di perusahaan besar, ratusan ribu pengujian otomatis dan pemeriksaan keamanan berlapis adalah hal yang umum
- Ini bukan bidang yang bisa dengan “mudah” diterapkan auto-coding berbasis LLM
- Riwayat commit proyek ini menunjukkan dengan menarik sampai di level mana LLM bisa berfungsi sebagai alat bantu
- Namun, beberapa cacat adalah jenis kesalahan yang juga sering dilakukan baik oleh LLM maupun manusia, dan contoh serupa juga ditemukan di komunitas lama seperti jawaban Stack Overflow
- Pada area kode yang menuntut ketelitian dan kecermatan, AI maupun manusia sama-sama membutuhkan perhatian yang sangat detail
- Untuk meninjau kode dengan bantuan LLM atau mempercayai hasilnya, pengalaman implementasi langsung serta pemikiran System 2 tetap wajib
- Untuk pekerjaan sederhana/non-kritis, LLM bisa sangat memadai, tetapi untuk sistem utama yang berkaitan dengan autentikasi atau keamanan, desain dan implementasi yang dipimpin ahli tetap lebih disarankan
2 komentar
Cloudflare membangun OAuth bersama Claude dan membuka semua prompt-nya
Opini Hacker News
Kasus ini secara langsung menunjukkan bahwa saat berinteraksi dengan LLM, dibutuhkan banyak pengetahuan domain. Misalnya, pengembang biasa mungkin tidak akan menyadari “cacat fatal” yang Claude karang di tengah jalan. Rasa janggal terhadap perubahan ke PBKDF2 juga muncul karena adanya keahlian domain. Kesimpulan saya: untuk memanfaatkan LLM secara efektif, dibutuhkan reviewer yang kompeten dan seorang ‘pemimpin’. Jika Anda tidak lebih paham dari LLM tentang topik tersebut, maka penggunaannya harus dibatasi pada hal yang kurang penting, atau Anda harus punya cukup banyak waktu untuk memverifikasi semua keluarannya
Dalam lingkungan baru seperti ini, saya jadi penasaran dari mana para pakar domain nantinya akan muncul. Pada akhirnya, siapa yang bisa benar-benar memahami sesuatu sedalam itu?
Setiap kali saya mendengar pendapat seperti ‘LLM dipakai hanya untuk bidang yang tidak kita kuasai, kalau ahli ya menulis kode sendiri’, saya justru bingung. Malah para ahli lebih mampu meninjau output LLM dengan akurat, dan semakin saya bisa menjelaskan apa yang saya inginkan dengan cara yang mendekati cara pikir pakar domain, semakin baik hasilnya. Sebenarnya ini masuk akal saja (karena LLM adalah mesin teks yang dihasilkan secara statistik)
LLM punya kecenderungan terlalu mudah menambahkan default, penanganan pengecualian, dan berbagai jalan memutar. Akibatnya, kode yang terlihat seolah berjalan bisa dengan mudah terbentuk, padahal sebenarnya bermasalah atau akan segera gagal. Di
CLAUDE.mdyang saya tulis, saya sudah berkali-kali menekankan hal ini, tetapi hasil seperti itu tetap sering munculSaya menangani sebagian besar pekerjaan deployment k8s dengan LLM. Memang cepat menghasilkan sesuatu yang berjalan, tetapi saya selalu harus terus mengingatkan agar selalu memakai secret dan jangan meng-commit kredensial dalam bentuk plaintext. Kesalahan seperti ini benar-benar berbahaya. Tutorial pendidikan sering mengabaikan keamanan demi fokus pada dasar-dasar, dan sepertinya karena terlalu banyak contoh seperti itu dalam data pelatihan LLM, output seperti itulah yang muncul
Seiring waktu, saya berharap alat coding AI akan bisa meneliti pengetahuan domain sendiri. Beberapa alat ‘riset AI’ yang sudah ada memang sangat hebat dalam hal ini, tetapi belum terintegrasi dengan baik ke alat coding. Penelitian itu bisa merujuk bukan hanya ke internet publik, tetapi juga pengetahuan domain dalam dokumentasi internal perusahaan. Namun, ada juga pengetahuan yang hanya ada di kepala seseorang, jadi pengguna tetap harus menyampaikannya sendiri
Baru-baru ini saya menulis Kafka consumer dengan bantuan AI untuk migrasi data. Efek AI paling maksimal terasa pada proyek jangka pendek, dibangun dari nol, dan dalam situasi ketika saya cukup paham bahasanya (Go) tetapi sudah lama tidak memakainya. Semua data masuk lewat satu topic, jadi untuk menjaga performa saya mengimplementasikan pemrosesan paralel yang cukup kompleks. Secara keseluruhan rasanya AI membuat saya sekitar 2 kali lebih cepat. Terutama ketika saya sesekali lupa sintaks Go, lebih membantu bertanya langsung ke AI daripada mencari sendiri. Tapi ada setidaknya 4 bug laten tersembunyi (selain bug-bug yang jelas, yang jumlahnya jauh lebih banyak). Kalau saya tidak terbiasa dengan Kafka atau multithreading, mungkin saya akan langsung melepasnya ke produksi. Untuk proyek besar/jangka panjang, peningkatannya ada di kisaran 10–20%. Dengan model terbaru, memang seperti itulah arahnya. Secara keseluruhan, ini mirip dengan kenaikan produktivitas yang dulu kita dapat saat beralih ke bahasa dengan manajemen memori. Jauh dari bayangan PM menggantikan developer (setidaknya melihat laju perubahan 3 tahun terakhir). Kekhawatiran saya yang sebenarnya justru kalau developer level menengah yang ‘jago secara teknis’ menjadi 10 kali lebih efisien berkat AI, mereka bisa jadi lebih berbahaya karena tidak mampu menemukan atau menangani bug-bug halus. Engineer senior/staff tampaknya tidak akan sanggup menahan banjir review. Dan saya juga khawatir proses bertumbuh dari junior ke senior akan makin rapuh. Programmer copy-paste saja sudah jadi masalah, dan AI memperkuat pola itu. Pasar pada akhirnya akan menyelesaikannya, tetapi saya cemas itu bisa memakan waktu puluhan tahun
Bug yang dihasilkan AI benar-benar licik. Saya sendiri pernah menyuruh AI menulis kode multithread dan benar-benar memasukkan bug halus ke produksi. Walaupun sudah direview dan diuji, tingkat konsentrasinya tidak sama seperti saat kita menulisnya sendiri dengan tangan. Untuk sementara, rasanya perlu memperlakukan kode buatan AI dengan asumsi ada bug-bug umum yang harus dicek lebih dulu, dan membatasinya pada area yang tidak berdampak fatal
Saya juga merasakan peningkatan sekitar 10–20% untuk ‘pekerjaan penting’. Ini memang perubahan nyata, tetapi tidak mengubah esensi pengembangan perangkat lunak. Pada akhirnya, ini menegaskan lagi tesis Brooks dalam "No Silver Bullet"
Saya juga setuju dengan poin tentang ‘badai teknis tingkat menengah’. Terutama di industri konsultasi, veteran sering diperlakukan seolah nilai dibanding biayanya rendah. Dulu saya juga termasuk orang yang bekerja cepat, dan kemudian harus bersusah payah menjelaskan kelemahan solusi jangka pendek kepada PM nonspesialis. Perusahaan IT besar mungkin akan cepat menangkap masalah seperti ini, tetapi kenyataannya kode yang menangani data keuangan atau medis sering ditulis oleh tenaga kontrak jangka pendek yang murah. Situasi ini sudah bermasalah bahkan sebelum LLM muncul. Sekarang ini pasti menjadi masa yang jauh lebih berat bagi developer yang sensitif terhadap isu keamanan
Anda bilang menemukan bug halus di kode hasil generasi; saya jadi bertanya-tanya bagaimana kalau bug seperti itu dideteksi otomatis lewat test code yang juga dibuat AI. Tentu saja test code-nya sendiri bisa saja punya bug, tetapi saya bisa membayangkan skenario masa depan di mana kita lebih fokus meninjau hasil tes daripada kode hasil generasinya
Anda menyebut pemrosesan paralel yang kompleks, tapi bukankah itu area yang bisa diselesaikan dengan memanfaatkan partition dan consumer-group?
Rasanya sesak melihat orang-orang yang begitu percaya pada LLM dan bekerja dengan cara ‘terjun dari tebing’, bersandar tanpa kritik. Sangat berbahaya jika sepenuhnya bergantung pada kotak hitam dan bahkan menyerahkan verifikasi kepadanya. Selain itu, strukturnya menghabiskan energi dalam jumlah besar, dan juga dipakai sebagai alasan untuk menggantikan manusia. Jujur saya tidak percaya lingkungan seperti ini akan membuat hidup 10 kali lebih baik
Ketika membandingkan proses menulis sendiri dengan memverifikasi hasil buatan orang lain (terutama kode hasil LLM), manusia sering cenderung tertipu oleh tampilan yang meyakinkan dan menerima masalah dengan kurang kritis. ‘Bentuk’ kode juga sangat memengaruhi kemampuan menemukan bug. Untuk memverifikasinya, salah satu cara adalah sengaja menyisipkan bug ke dalam kode dan bereksperimen apakah reviewer kode bisa menemukannya. Kalau kita mengimplementasikan sesuatu sendiri dengan tangan, kita berpikir jauh lebih lambat dan teliti serta lebih memperhatikan detail (itulah sebabnya bug tak terduga juga bisa ditemukan). Karena itu, untuk tujuan belajar, orang sering merekomendasikan menulis sendiri ‘versi mainan’ dari suatu tool. Ini berkaitan dengan struktur kognitif manusia
Di artikel disebutkan bahwa komentar yang tidak perlu tidak banyak, tetapi di kode aslinya ada komentar tak bermakna seperti
// Get the Origin header from the requestKomentar seperti ini adalah tanda jelas penggunaan LLM; tidak ada gunanya dan selalu saya hapus
Bagi manusia komentar seperti ini tidak berguna, tetapi dari sudut pandang LLM, jika fungsi kode di bawahnya juga dijelaskan dalam bahasa alami, itu mungkin bisa berperan seperti semacam Rosetta Stone yang membantu pemahaman. Mungkin itu dibayar dengan konsumsi token yang lebih besar, tetapi saya jadi ingin menguji apakah LLM benar-benar melakukan edit lebih baik pada kode yang komentarnya berlebihan
Saya juga punya pengalaman bahwa Claude sangat sering menulis komentar yang tidak berguna dan redundan seperti ini
Satu eksperimen yang ingin saya usulkan adalah membekukan satu branch kode, lalu memakai AI di satu sisi untuk membuat dan menyembunyikan kerentanan, dan di sisi lain untuk mencari dan memperbaikinya. Jadi, semacam menerapkan proses evolusi catur ke pengembangan kode
Saya adalah penulis library ini sendiri (lebih tepatnya, penulis prompt-nya). Saya bukan ahli OAuth setingkat Neil, tetapi cukup paham, dan saya sangat senang dia melakukan code review. Ada kesalahpahaman soal “YOLO CORS”, dan itu bukan sekadar kesalahan pemula yang ceroboh. Pengaturan CORS ini dibuat dengan sengaja setelah dipikirkan matang-matang. Saya hanya menonaktifkan CORS pada endpoint OAuth API (pertukaran token, registrasi client) dan endpoint API yang membutuhkan OAuth bearer token. Karena endpoint-endpoint ini tidak diautentikasi dengan kredensial browser (cookie, dll.), saya menilai tidak ada yang sebenarnya dilindungi oleh CORS. Inti CORS adalah lapisan keamanan yang mencegah kredensial dilampirkan secara otomatis, sedangkan bearer token harus dilampirkan secara eksplisit oleh client, sehingga tetap aman lintas-origin. Bahkan, saya sudah lama pernah berdebat dengan penulis spesifikasi CORS dan selalu berargumen bahwa keamanan sejati datang dari penggunaan bearer token alih-alih kredensial browser. Sementara itu, untuk kritik bahwa pembuatan token ID tidak efisien, saya tidak menganggapnya sampai level ‘fatal’. Keamanannya sendiri tidak bermasalah, dan algoritmenya bisa diubah nanti dengan bebas. Soal 21 commit ke
maindalam satu hari oleh satu orang, itu muncul seperti itu di GitHub karena penulisan ulang riwayat git yang membuat tanggalnya tampak terdistorsi. Terima kasih banyak atas pujian terhadap implementasi kriptografinya. Itu bukan hasil AI, melainkan karena saya memberi instruksi desain yang eksplisitAnda mengatakan “menonaktifkan header CORS pada OAuth API”, tetapi secara teknis yang dilakukan adalah menyetel header CORS sedemikian rupa sehingga aturan CORS menjadi tidak aktif. Dalam konteksnya memang cukup jelas, tetapi bisa membingungkan, jadi saya tambahkan penjelasan ini
Saya penasaran apakah Cloudflare berencana memakai library ini di produksi sungguhan
Banyak jawaban Stack Overflow yang populer juga penuh dengan kesalahan yang sama, dan memikirkan bahwa Claude mungkin belajar dari sana cukup mengkhawatirkan. Yang lebih menakutkan daripada celah keamanan atau kesalahan itu sendiri adalah kemungkinan seluruh basis pengetahuan masyarakat membeku pada jawaban internet populer dari era sebelum LLM
Melihat bahwa implementasi OAuth di ForgeRock punya ratusan bug keamanan, dan itu terjadi meskipun sudah ada ratusan ribu automated test, threat modeling, SAST/DAST kelas atas, expert review, dan sebagainya, saya kembali merasakan betapa sulitnya OAuth. Beberapa orang bahkan menyebutnya sebagai implementasi ‘kebakaran tempat sampah’. Saya sendiri belum pernah membaca spesifikasinya atau mencoba mengimplementasikannya
Setiap kali saya pernah terlibat dalam implementasi OAuth, rasanya selalu sangat mengerikan dan kompleks
OAuth memang benar-benar merepotkan, dan terlalu banyak niche case
Sebenarnya kode yang baru ditulis memang selalu akan punya bug. Semakin kompleks, semakin pasti. Itulah sebabnya perusahaan berusaha memakai kode dan tool yang ‘battle tested’. Di luar candaan, menarik melihat bagaimana Anthropic memakai AI generatif mereka sendiri secara praktis pada kode mereka. Saya penasaran apakah nanti mereka juga akan memakainya untuk MCP authentication API
“Ratusan ribu test” terdengar seperti sesuatu yang hanya bisa tumbuh secara kuantitatif, atau bahkan mungkin dibuat langsung oleh LLM. Saya juga penasaran siapa yang sebenarnya memeliharanya
Saya penasaran apakah tren orang meng-commit prompt mereka ke git akan menjadi hal yang umum, atau ini cuma semacam showcase saja