Checklist hardening mingguan untuk auth dan session produksi membantu tim backend memastikan area yang paling sering diserang tidak dibiarkan memburuk dari minggu ke minggu. Tujuannya bukan membuat sistem “sempurna”, tetapi menangkap drift konfigurasi, celah operasional, dan pola abuse sebelum berubah menjadi insiden.

Kalau Anda butuh format review mingguan yang langsung bisa dipakai, fokuskan pemeriksaan pada delapan area: rotasi secret, flag cookie dan session, TTL serta revocation, endpoint login/reset password, validasi upload, rate limiting, logging aman, dan alert anomali. Kombinasi ini memberi hasil praktis karena mencakup kontrol pencegahan, deteksi, dan respons.

Apa yang diperiksa setiap minggu, dan kenapa

Auth dan session sering gagal bukan karena satu bug besar, melainkan karena akumulasi hal kecil: cookie tanpa flag yang tepat, token terlalu lama hidup, secret tidak pernah diganti, endpoint reset password bocor lewat error message, atau log yang tanpa sengaja menyimpan token. Review mingguan berguna untuk memeriksa hal-hal yang mudah berubah akibat deploy, migration, atau perubahan integrasi.

Checklist ini cocok dipakai dalam weekly review oleh tim backend, SRE, atau security champion. Gunakan sebagai baseline; tambahkan item yang spesifik dengan arsitektur Anda, misalnya JWT, session server-side, OAuth, SSO enterprise, atau layanan upload terpisah.

Checklist hardening mingguan untuk auth dan session produksi

1. Secret handling dan rotasi kredensial

  • Verifikasi semua secret kritis punya owner dan sumber tunggal: database password, signing key token, API key email/SMS, secret reset password, secret session, webhook secret.
  • Pastikan secret tidak tersimpan di repository, file contoh, log deploy, atau dashboard observability.
  • Tinjau umur secret: apakah ada yang sudah terlalu lama tidak dirotasi.
  • Pastikan ada prosedur rotasi tanpa downtime, terutama untuk signing key atau secret yang dipakai banyak instance.
  • Cek pemisahan environment: secret production tidak boleh dipakai di staging atau lokal.

Mengapa penting: banyak insiden auth bermula dari kebocoran credential operasional, bukan bypass login. Secret yang valid biasanya memberi akses penuh dan sulit dideteksi jika tidak ada rotasi dan audit.

Praktik yang aman: gunakan secret manager atau mekanisme injeksi environment yang terkontrol. Hindari menyimpan key mentah di image container, file statis, atau chat internal.

Catatan: rotasi secret harus dibarengi dukungan key versioning atau periode transisi. Jika aplikasi hanya mendukung satu key aktif, rotasi sering menyebabkan logout massal atau token langsung invalid.

2. Cookie, session, dan token flags

  • Cookie session harus memakai HttpOnly, Secure, dan SameSite yang sesuai.
  • Periksa domain dan path cookie: jangan terlalu luas jika tidak diperlukan.
  • Pastikan session ID diregenerasi setelah login, privilege change, atau event sensitif lain.
  • Pastikan logout benar-benar menghapus session/token, bukan hanya menghapus state di klien.
  • Tinjau apakah access token disimpan di tempat yang aman. Hindari local storage untuk token yang sangat sensitif jika model ancamannya mencakup XSS.

Mengapa penting: flag cookie mengurangi risiko pencurian lewat JavaScript, transport tidak terenkripsi, dan CSRF. Regenerasi session mencegah session fixation, sementara domain/path yang terlalu luas memperbesar permukaan serangan.

# Contoh atribut cookie yang umumnya diharapkan untuk session web produksi
Set-Cookie: session_id=...; Path=/; HttpOnly; Secure; SameSite=Lax

Trade-off: nilai SameSite yang terlalu ketat bisa mematahkan alur login lintas domain atau integrasi pihak ketiga. Jangan menyalin konfigurasi secara buta; uji berdasarkan flow nyata aplikasi Anda.

3. TTL, refresh, dan revocation

  • Periksa TTL session dan token: jangan terlalu panjang tanpa alasan bisnis yang jelas.
  • Bedakan token pendek dan token panjang: access token semestinya lebih singkat daripada refresh token atau session persisten.
  • Pastikan ada mekanisme revocation untuk logout, reset password, perubahan email, perubahan peran, dan respons insiden.
  • Audit token zombie: token yang masih valid padahal akun sudah dinonaktifkan, password sudah diubah, atau role sudah dicabut.
  • Pastikan session idle timeout dan absolute timeout dipertimbangkan bila risiko aplikasi tinggi.

Mengapa penting: token yang bocor akan tetap berguna selama masih valid. TTL pendek mempersempit jendela serangan, tetapi tanpa revocation Anda tetap kesulitan memutus akses saat terjadi kompromi.

Kesalahan umum: hanya mengandalkan expiry tanpa daftar pencabutan, atau sebaliknya membuat token sangat pendek tetapi refresh flow tidak aman sehingga beban dan kompleksitas meningkat.

4. Audit endpoint login, registrasi, dan reset password

  • Periksa respons error: jangan membocorkan apakah email/username terdaftar jika tidak diperlukan.
  • Pastikan reset password memakai token sekali pakai, TTL pendek, dan invalid setelah berhasil dipakai.
  • Cek apakah login dan reset password punya rate limit terpisah dari endpoint umum.
  • Audit redirect pasca-login agar tidak membuka celah open redirect.
  • Pastikan MFA step-up diterapkan untuk aksi sensitif jika sistem mendukungnya.
  • Tinjau login sosial atau OAuth callback: state/nonce harus divalidasi.

Mengapa penting: endpoint auth adalah target utama enumeration, brute force, credential stuffing, dan token theft. Error message yang terlalu informatif sering dianggap sepele, padahal sangat membantu penyerang memverifikasi akun yang valid.

// Contoh respons yang lebih aman untuk reset password
{
  "message": "Jika akun terdaftar, instruksi reset password akan dikirim."
}

Debugging tip: jika tim produk meminta pesan error lebih spesifik, evaluasi konteksnya. Untuk halaman internal admin mungkin bisa lebih detail, tetapi untuk endpoint publik sebaiknya tetap generik.

5. Validasi input dan upload file

  • Validasi ukuran file di gateway dan aplikasi, bukan hanya di UI.
  • Validasi MIME type dan signature file bila memungkinkan; jangan percaya ekstensi nama file saja.
  • Gunakan allowlist tipe file yang benar-benar dibutuhkan.
  • Ubah nama file saat simpan untuk menghindari path traversal, tabrakan nama, atau eksekusi tak terduga.
  • Pastikan file upload tidak disajikan dari direktori eksekusi aplikasi bila arsitektur Anda memungkinkan.
  • Pertimbangkan scanning malware untuk jenis file berisiko atau untuk aplikasi enterprise.

Mengapa penting: upload sering diperlakukan sebagai fitur biasa, padahal bisa menjadi jalur masuk untuk RCE, penyimpanan konten berbahaya, serangan resource exhaustion, atau penyebaran malware.

// Pseudocode validasi upload
if (file.size > MAX_UPLOAD_BYTES) reject("file terlalu besar")
if (!ALLOWED_MIME.includes(detectedMime)) reject("tipe file tidak diizinkan")
if (!isSafeFilename(generatedName)) reject("nama file tidak valid")
saveToObjectStorage(generatedName, fileStream)

Kesalahan umum: hanya memeriksa Content-Type dari request, membiarkan file disimpan dengan nama asli pengguna, atau menyajikan file langsung dari lokasi yang dapat dieksekusi web server.

6. Rate limiting dan pencegahan abuse

  • Pastikan endpoint login, reset password, OTP, dan resend code memiliki pembatasan sendiri.
  • Gunakan beberapa dimensi pembatasan: per IP, per akun, per device fingerprint bila ada, dan per subnet atau ASN jika relevan.
  • Audit apakah limit dapat dibypass lewat variasi header, jalur endpoint alternatif, atau race condition.
  • Tambahkan backoff atau cooldown untuk percobaan berulang.
  • Pisahkan proteksi bot dan proteksi abuse API; kebutuhannya tidak selalu sama.

Mengapa penting: rate limit bukan hanya anti-brute-force. Ia juga melindungi biaya operasional, SMS/email abuse, spam pendaftaran, dan gangguan layanan akibat traffic berulang yang sah secara sintaks tetapi berbahaya secara perilaku.

# Contoh kebijakan yang sering masuk akal sebagai baseline konseptual
- login: limit ketat per IP + per akun
- reset password: limit ketat per akun + cooldown pengiriman email
- OTP verify: limit ketat per akun/per device
- resend OTP: limit lebih ketat dari verify

Trade-off: limit yang terlalu agresif bisa memblokir pengguna sah di jaringan kantor, kampus, atau operator seluler. Karena itu observasi false positive sama pentingnya dengan jumlah request yang ditahan.

7. Logging aman dan audit trail

  • Pastikan password, token, OTP, cookie, authorization header, dan secret tidak masuk log aplikasi.
  • Periksa redaction di level aplikasi, reverse proxy, dan APM.
  • Log event penting: login sukses/gagal, logout, reset password diminta/digunakan, perubahan email, perubahan role, revoke session.
  • Simpan konteks yang cukup untuk investigasi tanpa merekam data sensitif secara berlebihan.
  • Audit retensi log dan siapa yang bisa mengaksesnya.

Mengapa penting: log adalah alat deteksi utama saat ada penyalahgunaan, tetapi juga sering menjadi sumber kebocoran terbesar. Nilai audit trail terletak pada kemampuan menjawab “siapa melakukan apa, kapan, dari mana”, bukan pada menyalin seluruh payload mentah.

// Contoh redaction sederhana sebelum logging
function redactAuth(headers) {
  const clone = { ...headers }
  if (clone.authorization) clone.authorization = "[REDACTED]"
  if (clone.cookie) clone.cookie = "[REDACTED]"
  return clone
}

8. Alert anomali dan deteksi dini

  • Pasang alert untuk lonjakan login gagal, reset password, OTP resend, atau pembuatan akun.
  • Alert untuk pola tidak biasa: banyak akun dari satu IP, satu akun dari banyak negara/ASN, atau kenaikan tajam session revoke.
  • Tinjau dashboard auth mingguan, bukan hanya saat insiden.
  • Pastikan alert bisa ditindaklanjuti: ada runbook, owner, dan ambang yang realistis.

Mengapa penting: banyak serangan abuse tidak terlihat sebagai error aplikasi. Tanpa observability perilaku, tim baru sadar setelah pengguna mengeluh atau biaya notifikasi melonjak.

Prinsip praktis: alert yang baik harus mengarah ke tindakan. Jika alert hanya memberi angka tanpa konteks akun, endpoint, atau sumber traffic, biasanya akan diabaikan.

Template checklist weekly review yang bisa langsung dipakai

Berikut template yang bisa dipakai saat weekly review tim backend. Tandai setiap item dengan OK, Perlu tindak lanjut, atau Tidak relevan.

A. Auth dan session

  • Cookie session memakai HttpOnly, Secure, dan SameSite yang sesuai.
  • Session ID diregenerasi setelah login dan perubahan privilege.
  • TTL session/access token masih sesuai kebijakan risiko.
  • Refresh token atau session persisten punya mekanisme pencabutan.
  • Logout menghapus state server-side, bukan hanya klien.
  • Password change dan account disable memutus session lama.

B. Secret handling

  • Tidak ada secret baru yang masuk repository, image, atau log.
  • Owner dan tanggal rotasi secret terdokumentasi.
  • Secret production terpisah dari staging/lokal.
  • Prosedur rotasi sudah diuji untuk secret paling kritis.

C. Endpoint sensitif

  • Login, reset password, OTP, resend OTP, dan registrasi punya rate limit.
  • Respons endpoint reset password tidak mengungkap keberadaan akun.
  • Token reset password bersifat sekali pakai dan TTL pendek.
  • Tidak ada open redirect pada alur login atau reset.

D. Upload dan validasi input

  • Ukuran upload dibatasi di edge dan aplikasi.
  • Tipe file divalidasi dengan allowlist dan, bila memungkinkan, signature file.
  • Nama file dihasilkan ulang saat penyimpanan.
  • File tidak disajikan dari direktori eksekusi aplikasi.

E. Logging dan alert

  • Password, token, cookie, dan secret tidak masuk log.
  • Event auth penting tercatat dengan aman untuk audit.
  • Alert anomali login/reset/OTP aktif dan diuji.
  • Ada owner dan runbook untuk alert auth utama.

Quick wins vs perbaikan struktural

Quick wins minggu ini

  • Aktifkan atau koreksi flag cookie HttpOnly, Secure, SameSite.
  • Redact Authorization header, cookie, dan token dari log.
  • Tambahkan rate limit pada login, reset password, dan resend OTP.
  • Ubah pesan reset password menjadi generik untuk mencegah enumeration.
  • Batasi ukuran upload dan terapkan allowlist MIME dasar.
  • Audit secret yang bocor ke repository atau file konfigurasi lama.

Kenapa ini prioritas: quick wins biasanya berbiaya rendah, risikonya jelas, dan dampaknya langsung terasa. Mereka tidak menyelesaikan semua masalah, tetapi sering menutup celah paling murah bagi penyerang.

Perbaikan struktural

  • Migrasi ke secret manager dengan audit trail dan rotasi terkontrol.
  • Membangun sistem revocation token/session yang konsisten di seluruh layanan.
  • Memisahkan auth service, risk engine, atau abuse detection bila skala sudah menuntut.
  • Menerapkan observability khusus auth: dashboard, baseline, dan alert perilaku.
  • Menambahkan scanning file upload dan pipeline karantina untuk file berisiko.
  • Membangun kebijakan adaptive rate limiting berdasarkan perilaku, bukan angka statis semata.

Kenapa ini struktural: perubahan ini menyentuh arsitektur, proses operasional, dan kadang model data. Hasilnya lebih tahan lama, tetapi memerlukan koordinasi lintas tim.

Kesalahan umum yang sering terlewat

  • Menganggap HTTPS saja cukup. HTTPS penting, tetapi tidak menggantikan HttpOnly, revocation, atau rate limit.
  • Mengandalkan expiry tanpa revoke. Saat akun dikompromi, Anda butuh cara memutus akses sebelum token kedaluwarsa.
  • Mencampur concern UX dan keamanan tanpa batas. Pesan error yang terlalu membantu bisa mempercepat enumeration.
  • Menganggap upload aman karena hanya gambar. Gambar pun bisa dipakai untuk abuse ukuran, parser bug, atau konten berbahaya.
  • Menyimpan data sensitif di log demi debugging. Ini memperluas blast radius insiden.
  • Membuat rate limit global saja. Satu limit umum sering gagal melindungi endpoint sensitif.
  • Tidak menguji skenario logout, password change, dan disable account. Banyak sistem tampak aman sampai diuji terhadap session lama yang masih aktif.

Cara menjalankan review mingguan tanpa jadi ritual kosong

  1. Tetapkan owner untuk tiap area: auth/session, secret, observability, upload.
  2. Bandingkan dengan minggu sebelumnya: bukan hanya status saat ini, tetapi perubahan konfigurasi, lonjakan metrik, dan exception baru.
  3. Catat temuan sebagai tindakan konkret, misalnya “tambahkan revoke saat password change”, bukan “perbaiki keamanan auth”.
  4. Prioritaskan berdasarkan blast radius: hal yang memengaruhi semua pengguna harus naik dulu.
  5. Uji satu skenario nyata tiap minggu: brute-force ringan di staging, reset password flow, upload file terlarang, atau logout dari semua perangkat.

Weekly review yang baik bukan audit besar-besaran, melainkan inspeksi rutin terhadap kontrol yang paling mungkin gagal. Jika tim Anda konsisten menjalankan checklist hardening mingguan untuk auth dan session produksi, banyak masalah akan tertangkap saat masih kecil: sebelum secret bocor dipakai, sebelum token zombie menumpuk, dan sebelum endpoint auth menjadi pintu utama abuse.