Checklist hardening auth saat aplikasi lama dipercepat AI perlu diperlakukan sebagai pekerjaan rekayasa, bukan sekadar review cepat. Ketika aplikasi lama dimodernisasi atau dipercepat dengan coding agent modern, perubahan kecil pada controller, middleware, template, atau flow reset password bisa membuka celah yang sebelumnya tidak ada, terutama jika tim terlalu fokus pada kecepatan delivery.

Ini sejalan dengan konteks yang sering muncul dalam diskusi tentang aplikasi lama dan aplikasi baru di era coding agent modern: perubahan menjadi jauh lebih cepat, tetapi sistem lama membawa asumsi, dependency, dan perilaku historis yang tidak selalu terlihat dari pembacaan kode singkat. Karena itu, sebelum merilis perubahan auth pada aplikasi lama, tim perlu menjalankan checklist hardening yang konkret, menguji alur dari ujung ke ujung, dan memverifikasi bahwa percepatan implementasi tidak mengorbankan kontrol dasar keamanan.

Mengapa aplikasi lama yang dipercepat AI lebih berisiko pada auth

Pada aplikasi lama, auth jarang berdiri sendiri. Ia biasanya terhubung ke session store, template server-side, cookie lama, endpoint mobile, job email, admin panel, dan kadang integrasi SSO parsial. Coding agent dapat membantu menulis ulang route, menambah middleware, atau merapikan form dengan cepat, tetapi beberapa risiko berikut sering lolos:

  • Asumsi implisit tidak terdokumentasi, misalnya session hanya aman jika login selalu lewat satu endpoint lama.
  • Perubahan auth flow yang tampak kecil, tetapi mengubah urutan validasi, regenerasi session, atau penanganan token.
  • Duplikasi endpoint untuk web, mobile, dan admin yang tidak semua mendapat proteksi setara.
  • Legacy compatibility yang membuat tim mempertahankan perilaku lama berbahaya karena takut memutus pengguna.
  • Refactor cepat yang memindahkan secret atau token ke tempat yang lebih mudah diakses, misalnya file config, log, atau variabel client-side.

Masalah utamanya bukan AI itu sendiri, melainkan kecepatan perubahan pada sistem dengan konteks historis yang besar. Karena itu, hardening auth harus dimulai dari pemetaan flow nyata, bukan asumsi dari framework.

Checklist hardening auth: mulai dari audit auth flow

1. Petakan semua jalur autentikasi dan pemulihan akun

Sebelum mengubah apa pun, buat inventaris semua flow yang menyentuh identitas pengguna:

  • Login web
  • Login mobile atau API
  • Logout
  • Remember me
  • Refresh session
  • Ganti password
  • Lupa password / reset password
  • Verifikasi email atau aktivasi akun
  • Impersonation admin jika ada
  • Magic link, OTP, atau SSO jika ada

Untuk tiap flow, jawab pertanyaan ini:

  • Input apa saja yang diterima?
  • State apa yang berubah?
  • Token atau session apa yang dibuat, dipakai, atau dicabut?
  • Apakah ada redirect yang bisa dimanipulasi?
  • Apakah endpoint hanya untuk browser, atau juga dipakai script/API?
  • Apakah log menyimpan data sensitif?

Hasil audit yang baik biasanya berupa tabel sederhana: endpoint, metode, aktor, proteksi, dependency, dan risiko. Ini jauh lebih berguna dibanding hanya membaca diff hasil bantuan coding agent.

2. Cari trust boundary yang berubah diam-diam

Saat aplikasi lama dipercepat, boundary sering bergeser tanpa sengaja. Contohnya:

  • Validasi yang dulu hanya terjadi di server dipindah ke frontend.
  • Endpoint internal kini bisa diakses publik karena route grouping berubah.
  • Admin action sekarang memakai komponen UI baru tetapi tanpa pemeriksaan otorisasi yang sama.
  • Cookie session dipakai lintas subdomain tanpa evaluasi ulang risiko.

Jika boundary berubah, auth harus dievaluasi ulang meski fitur bisnis tampak sama.

Quick wins dengan dampak besar

Jika waktu terbatas, mulai dari perubahan yang umumnya memberi pengurangan risiko paling cepat.

Rotasi session setelah login dan perubahan privilege

Session fixation terjadi ketika penyerang berhasil memaksa korban memakai ID session yang sudah diketahui, lalu korban login dengan session itu. Jika aplikasi tidak meregenerasi session setelah autentikasi berhasil, penyerang bisa mengambil alih session.

Lakukan regenerasi session minimal pada kondisi berikut:

  • Setelah login berhasil
  • Setelah reset password selesai
  • Setelah eskalasi hak akses atau masuk ke area admin
  • Setelah verifikasi MFA jika ada

Secara umum, pola aman terlihat seperti ini:

// Pseudocode, sesuaikan dengan framework Anda
if (credentialsValid(user, password)) {
  rotateSessionId();
  attachAuthenticatedUser(user.id);
  clearPreAuthState();
  setSecureSessionCookie();
}

Kesalahan umum: hanya menyimpan user ke session lama tanpa rotasi ID session.

Cookie flags yang benar

Untuk session berbasis cookie, pastikan minimal:

  • HttpOnly: mencegah akses JavaScript ke cookie session.
  • Secure: cookie hanya dikirim melalui HTTPS.
  • SameSite: membantu mengurangi CSRF, biasanya Lax cocok untuk banyak aplikasi web tradisional. Jika perlu cross-site secara sah, evaluasi dengan hati-hati.
  • Path dan Domain sesempit mungkin.

Anti-pattern yang sering muncul pada aplikasi lama adalah mengatur domain cookie terlalu luas agar kompatibel lintas subdomain, padahal beberapa subdomain tidak dikelola dengan standar keamanan yang sama.

Rate limit untuk login, reset, dan endpoint sensitif

Jangan hanya memberi rate limit pada login. Terapkan juga pada:

  • Permintaan reset password
  • Verifikasi OTP atau token
  • Endpoint cek ketersediaan akun jika bisa dipakai enumerasi
  • Endpoint resend email verifikasi

Rate limit sebaiknya mempertimbangkan kombinasi sinyal seperti IP, account identifier, dan device fingerprint ringan bila tersedia. Hanya berbasis IP sering tidak cukup untuk jaringan bersama, tetapi hanya berbasis email juga mudah disalahgunakan.

Tujuan rate limit bukan menghentikan semua serangan, melainkan menaikkan biaya abuse dan memberi sinyal observabilitas yang bisa ditindaklanjuti.

Hardening pada flow yang paling sering bermasalah

Password reset

Flow reset password adalah sumber bug klasik, terutama saat dirombak cepat. Checklist minimumnya:

  • Token reset harus acak kuat, sekali pakai, dan punya masa berlaku pendek.
  • Token jangan disimpan atau dilog dalam bentuk yang mudah disalahgunakan.
  • Respons untuk email yang ada dan tidak ada sebaiknya serupa untuk mengurangi account enumeration.
  • Setelah password diubah, cabut session lama atau minimal paksa re-auth pada session lain sesuai model ancaman aplikasi.
  • Rotasi session pada browser yang sedang menyelesaikan reset.
  • Jangan kirim password baru via email.

Pola aman untuk penyimpanan token reset biasanya berupa penyimpanan hash token, bukan token mentah:

// Saat membuat reset token
rawToken = randomSecureToken();
saveResetTokenHash(userId, hash(rawToken), expiresAt);
sendEmail(user.email, buildResetLink(rawToken));

// Saat verifikasi
record = findResetRecord(userId);
if (!record || record.expiresAt < now()) reject();
if (!constantTimeEquals(hash(submittedToken), record.tokenHash)) reject();
consumeResetToken(record.id);

Mengapa ini penting? Jika database atau log bocor, token mentah yang masih aktif bisa langsung dipakai. Hashing mengurangi dampak kebocoran data.

CSRF pada form berbasis session

Jika aplikasi memakai autentikasi berbasis cookie/session untuk browser, proteksi CSRF tetap relevan meskipun Anda sudah mengatur SameSite. Checklistnya:

  • Semua operasi state-changing memakai token CSRF server-side.
  • Token divalidasi pada POST/PUT/PATCH/DELETE sesuai model aplikasi.
  • Jangan mengandalkan header tertentu saja jika browser normal juga memakai form tradisional.
  • Logout via GET sebaiknya dihindari.

Kesalahan umum saat modernisasi UI adalah mengganti form lama menjadi komponen async lalu lupa menyertakan token CSRF pada request tertentu.

Validasi input yang konsisten

Input auth sering tampak sederhana, tetapi validasi yang longgar bisa berdampak pada bypass, error leakage, atau abuse. Pastikan:

  • Email, username, redirect target, token, dan kode OTP divalidasi dengan aturan yang jelas.
  • Panjang input dibatasi untuk mencegah payload aneh atau beban berlebih.
  • Normalisasi dilakukan secara sadar, misalnya trimming whitespace pada field tertentu.
  • Redirect setelah login/reset divalidasi agar tidak menjadi open redirect.

Open redirect pada halaman login atau reset sering dianggap bug kecil, padahal bisa dipakai untuk phishing yang tampak meyakinkan.

Upload aman pada alur auth dan profil

Upload sering muncul di area yang terkait identitas, misalnya foto profil, dokumen verifikasi, atau lampiran support account recovery. Checklist minimumnya:

  • Validasi tipe file jangan hanya berdasarkan ekstensi.
  • Batasi ukuran file.
  • Simpan file di lokasi non-eksekutabel jika memungkinkan.
  • Gunakan nama file acak, bukan nama asli pengguna.
  • Jangan langsung memproses file dengan tool yang rentan tanpa sandbox atau pembatasan.
  • Jika file dapat diunduh publik, set content-type dan content-disposition dengan aman.

Area upload yang menempel pada account recovery berbahaya karena sering dikerjakan cepat dan diakses oleh agen support atau admin dengan privilege tinggi.

Secret, token, dan penyimpanan data sensitif

Jangan pindahkan secret ke tempat yang lebih mudah bocor

Saat coding agent membantu refactor config, perhatikan agar secret tidak berpindah ke:

  • Repository
  • File konfigurasi statis yang ikut terdeploy ke client
  • Log aplikasi
  • Error message
  • Screenshot atau fixture test

Gunakan secret manager atau mekanisme environment yang sesuai dengan platform Anda. Yang terpenting bukan nama tool, melainkan disiplin berikut:

  • Akses secret dibatasi sesuai kebutuhan service.
  • Secret bisa dirotasi.
  • Secret tidak dipakai ulang lintas environment.
  • Log dan tracing disaring agar tidak menampilkan token, cookie, authorization header, atau reset link.

Pisahkan credential, session, dan token aplikasi

Jangan campur cara penyimpanan semua data sensitif. Password harus di-hash dengan algoritma password hashing yang sesuai, session server-side harus memiliki kontrol expiry dan revocation, sedangkan token reset atau API key memiliki lifecycle sendiri. Mencampur semuanya ke satu tabel atau satu utilitas sering mempersulit kontrol keamanan dan audit.

Audit logging dan abuse prevention

Apa yang perlu dilog

Audit logging untuk auth harus cukup detail untuk investigasi, tetapi tidak membocorkan rahasia. Event yang umumnya perlu dicatat:

  • Login berhasil dan gagal
  • Logout
  • Permintaan reset password
  • Reset password berhasil
  • Perubahan email atau password
  • Lockout, throttle, atau challenge tambahan
  • Perubahan role atau privilege
  • Akses admin terhadap akun pengguna jika ada impersonation

Simpan metadata yang berguna seperti timestamp, user ID bila ada, identifier yang dinormalisasi, IP, user-agent ringkas, dan hasil keputusan. Hindari menyimpan password, token mentah, cookie, atau header authorization.

Deteksi abuse, bukan hanya pencatatan

Logging tanpa respons operasional sering tidak cukup. Tambahkan deteksi untuk pola berikut:

  • Banyak login gagal ke banyak akun dari satu sumber
  • Banyak reset password ke akun yang berbeda
  • Lonjakan resend verification
  • Perubahan email diikuti login dari lokasi tidak lazim
  • Aktivitas admin yang tidak biasa pada banyak akun

Respons bisa berupa throttle lebih ketat, captcha adaptif, alert ke tim keamanan, atau review manual untuk flow recovery sensitif. Trade-off-nya adalah friction pengguna. Karena itu, pasang kontrol paling ketat pada flow berisiko tinggi, bukan meratakan semua pembatasan ke semua pengguna.

Anti-pattern umum saat auth aplikasi lama dipercepat

  • Menganggap framework default sudah cukup padahal aplikasi punya custom flow lama di luar jalur standar.
  • Menambal UI tanpa menguji endpoint lama; endpoint lama sering tetap aktif dan tidak mendapat proteksi baru.
  • Menyamakan browser auth dan API auth tanpa memikirkan CSRF, storage token, dan revocation model yang berbeda.
  • Membiarkan error terlalu informatif, misalnya membedakan “email tidak ditemukan” dan “password salah” pada flow sensitif.
  • Memakai redirect target dari query string tanpa allowlist.
  • Tidak mencabut session lama setelah reset password atau perubahan email.
  • Menaruh token di log/debug toolbar saat troubleshooting.
  • Menguji hanya happy path dan tidak mencoba replay token, reuse session, atau request lintas origin.

Checklist implementasi yang bisa langsung dipakai

P0 — wajib sebelum rilis

  1. Petakan semua auth flow dan endpoint terkait.
  2. Regenerasi session ID setelah login dan perubahan privilege.
  3. Set cookie HttpOnly, Secure, dan SameSite yang sesuai.
  4. Aktifkan CSRF protection pada semua operasi state-changing berbasis session.
  5. Terapkan rate limit pada login, reset password, resend verification, dan verifikasi token/OTP.
  6. Amankan flow reset password: token acak, expiry, single use, respons anti-enumerasi, cabut session lama.
  7. Pastikan secret tidak muncul di repo, log, client bundle, atau error output.
  8. Tambahkan audit log untuk event auth penting tanpa data sensitif.

P1 — sangat disarankan

  1. Validasi redirect target dengan allowlist internal.
  2. Tinjau domain/path cookie agar tidak terlalu luas.
  3. Uji account enumeration pada login, reset, dan signup bila ada.
  4. Periksa upload pada flow profil/recovery.
  5. Tambahkan alert untuk lonjakan login gagal dan reset password.
  6. Review session revocation antar-device setelah password berubah.

P2 — penguatan lanjutan

  1. Tambahkan challenge adaptif untuk pola abuse tertentu.
  2. Audit impersonation admin dan justifikasi akses support.
  3. Segmentasi proteksi antara user biasa, admin, dan operator internal.
  4. Review dependency yang memproses token, email link, dan file upload.

Contoh verifikasi sebelum rilis

Sebelum deploy, lakukan verifikasi berbasis skenario, bukan hanya unit test. Berikut daftar cek yang praktis:

Uji manual minimal

  • Login berhasil harus menghasilkan session baru, bukan melanjutkan session pre-auth yang sama.
  • Logout harus menonaktifkan session yang sedang aktif.
  • Reset password link tidak bisa dipakai dua kali.
  • Session lama setelah reset password tidak lagi valid sesuai kebijakan aplikasi.
  • Form POST sensitif tanpa token CSRF harus ditolak.
  • Cookie session tampil dengan flag yang benar di browser/devtools.
  • Redirect setelah login tidak menerima URL eksternal sembarang.
  • Rate limit aktif saat percobaan login/reset berulang.
  • Log tidak memuat password, token reset, atau nilai cookie.

Contoh skenario HTTP untuk verifikasi dasar

# Cek header Set-Cookie pada login response
curl -k -i -X POST https://app.example.com/login \
  -d '[email protected]&password=wrong'

# Coba pakai ulang token reset yang sama dua kali
curl -k -i -X POST https://app.example.com/reset-password \
  -d 'token=TOKEN&password=NewPass123!'

Perintah di atas bukan pengujian lengkap, tetapi berguna untuk inspeksi cepat terhadap header, status code, dan perilaku token.

Hal yang perlu diperiksa di staging dan observability

  • Apakah reverse proxy atau CDN mengubah header cookie/security?
  • Apakah HTTPS dipaksa konsisten?
  • Apakah log sanitization tetap bekerja pada mode debug tertentu?
  • Apakah worker email mengirim link yang benar dan tidak mencatat token mentah?
  • Apakah route lama masih aktif setelah refactor?

Penutup

Checklist hardening auth saat aplikasi lama dipercepat AI pada dasarnya adalah cara menjaga agar kecepatan perubahan tidak merusak trust boundary yang sudah ada. Fokus utamanya bukan menambahkan semua kontrol keamanan sekaligus, melainkan memastikan flow inti—login, session, reset password, CSRF, secret handling, logging, dan abuse prevention—tetap benar saat sistem lama berubah cepat.

Jika Anda hanya mengambil beberapa langkah minggu ini, mulai dari audit auth flow, rotasi session, pengamanan reset password, cookie flags, CSRF, rate limit, dan audit logging. Kombinasi itu biasanya menutup sebagian besar celah yang paling sering muncul ketika aplikasi lama dimodernisasi dengan bantuan coding agent modern.