Lima Celah yang Dikunci, Bukan Dibenahi

Saya membuka berkas pengujian baru untuk modul autentikasi dan langsung menjumpai lima baris komentar identik: // characterization: current behavior, owner decision pending. Lima perilaku keamanan yang lemah tidak diperbaiki dan tidak dibungkam. Mereka dikunci apa adanya sebagai characterization test, lengkap dengan penanda bahwa keputusannya masih milik pemilik proyek. Dari luar, ini tampak seperti menunda pekerjaan yang seharusnya dikerjakan. Setelah membacanya satu per satu, saya justru menilai ini cara paling jujur untuk memetakan permukaan risiko sebelum mengubah apa pun.

Lima Temuan yang Dikunci

Pertama, registrasi membocorkan keberadaan akun. Endpoint register menjawab 409 yang spesifik ketika alamat surel sudah terverifikasi. Respons sejelas ini nyaman bagi pengguna, tapi juga menjadi oracle enumerasi: orang luar bisa memetakan alamat mana yang terdaftar hanya dengan mengamati perbedaan jawaban. OWASP menegaskan bahwa pesan galat autentikasi yang salah implementasi "can be used for the purposes of user ID and password enumeration", dan aplikasi sebaiknya merespons secara generik [1]. Sisi lain basis kode yang sama sudah memakai pola anti-enumerasi pada endpoint pengiriman ulang OTP dengan respons generik. Dua filosofi hidup berdampingan, dan commit ini tidak memihak; ia hanya mengunci fakta.

Kedua, verifikasi OTP berjalan di luar rate limiter. Login dibatasi ketat, tapi jalur HTTP untuk menebak kode OTP tidak melalui limiter yang membungkus endpoint kredensial lain. Ada batas percobaan di lapisan layanan, namun selama jalur permintaannya tak terbatas, biaya serangan dihitung dari sisi yang paling longgar.

Ketiga, pergantian kata sandi tidak mencabut JWT yang masih beredar. OWASP menulis bahwa setelah sesi terautentikasi, session ID atau token "is temporarily equivalent to the strongest authentication method used by the application" [2]. Token lama yang tidak dicabut punya kekuatan setara kata sandi yang barusan dianggap sudah diganti. Jika token itu bocor, pembajakan sesi tetap mungkin seolah tidak pernah ada pergantian kredensial.

Keempat, baris OTP disimpan sebelum surel terkirim. Fungsi issueOTP menulis row ke database lebih dulu, baru memanggil pengirim surel. Ketika pengiriman gagal, row tetap ada. Ini menyelamatkan jejak audit, tapi menyisakan state yang tidak sinkron dengan kenyataan komunikasi, dan state semacam ini biasanya baru terasa ketika proses lain membacanya.

Kelima, counter rate limiter hidup di memori proses. Prinsip Twelve-Factor menyatakan proses harus "stateless and share-nothing" dan memperingatkan bahwa "chances are high that a future request will be served by a different process" [3]. Konsekuensinya konkret: restart mengembalikan counter ke nol, dan dua replica berarti dua budget percobaan yang tidak pernah berbagi.

Mengapa Dikunci, Bukan Dibenahi

Insting pertama saya tentu saja langsung memperbaiki. Tapi memperbaiki diam-diam menghapus riwayat: tidak ada catatan mengapa perilaku itu pernah dipilih, tidak ada pembanding saat orang berikutnya mengusulkan perubahan. Characterization test mengubah lima kelemahan menjadi inventaris bernama. Setiap test membawa nama perilaku, asersi yang membekukan fakta, dan satu marker keputusan. Marker itu bukan alasan menunda tanpa batas; ia tiket keputusan yang eksplisit, bisa diprioritaskan, bisa ditagih.

Yang saya hargai dari pola ini: ia tidak pura-pura semua temuan sama urgensinya. Lima marker berarti lima diskusi terpisah, masing-masing dengan trade-off sendiri. Respons 409 bisa dipertahankan demi pengalaman pengguna lalu ditransisi bertahap ke respons generik. Rate limiter process-local naik prioritas karena menyentuh distribusi. Pencabutan token bisa dinegosiasikan dengan jendela kedaluwarsa yang lebih pendek sebagai jalan tengah. Peta dulu, jalan kemudian.

Tiga Pertanyaan untuk Menilai Temuan Serupa

Pertama, apakah perilaku melanggar prinsip dasar atau sekadar kurang sopan? Token yang tetap valid setelah kredensial berganti menyangkut definisi keamanan itu sendiri; kelas ini biasanya menolak penundaan panjang. Kedua, apakah basis kode sudah konsisten? Ketika satu endpoint sudah memakai pola anti-enumerasi, endpoint lain yang belum menjadi kandidat penyeragaman, bukan debat desain dari nol. Ketiga, apakah logikanya bergantung pada state lokal proses? Komponen keamanan yang menyimpan data di memori lokal akan kacau pada deployment terdistribusi; itu pertanda kuat untuk pindah ke penyimpanan bersama.

Setelah lima celah ini masuk inventaris, keputusan pemilik proyek tinggal soal urutan dan biaya, bukan soal menemukan ulang masalah. Itulah bedanya memperbaiki dengan ingatan dan memperbaiki dengan peta.

Sumber

[1] OWASP Authentication Cheat Sheet, diakses 11 Oktober 2026.
[2] OWASP Session Management Cheat Sheet, diakses 11 Oktober 2026.
[3] The Twelve-Factor App: Processes, diakses 11 Oktober 2026.