Security Debt di Auth: Audit Session dan Secret yang Tertinggal

Security debt di auth jarang muncul sebagai bug yang langsung terlihat. Sistem bisa tetap login, token masih valid, dan pengguna tidak mengeluh, tetapi di belakang layar ada banyak kontrol yang tertinggal: session tidak pernah benar-benar kedaluwarsa, cookie belum diberi flag yang tepat, secret bocor ke log, validasi input berbeda antar endpoint, dan brute force tetap mungkin karena rate limit tidak ada.

Masalahnya, utang keamanan seperti ini sering tidak bisa dibuktikan sekarang. Tidak ada insiden aktif, tidak ada exploit yang terlihat, dan tidak ada tiket yang mendesak. Namun justru di area auth, kelemahan kecil yang dibiarkan lama sering berubah menjadi jalur insiden besar. Audit yang baik bukan mencari kesempurnaan, tetapi mencari kontrol minimum yang harus bisa dijelaskan, diuji, dan dipantau.

Mengapa security debt di auth sering tidak terasa

Auth berada di jalur kritis, tetapi gejala buruknya sering samar. Sebuah sistem dapat terlihat sehat karena metrik bisnis berjalan normal, padahal kontrol keamanannya rapuh. Ini berbeda dari bug fungsional yang mudah direproduksi. Pada auth, banyak masalah baru terasa saat terjadi penyalahgunaan, kebocoran log, pencurian cookie, atau token lama dipakai ulang setelah akun berpindah tangan.

Beberapa alasan umum mengapa tim merasa sistem “masih aman”:

Tidak ada insiden yang terlihat. Ketiadaan sinyal bukan bukti kontrol memadai.
Flow login berhasil. Berhasil login tidak berarti session lifecycle aman.
Secret sudah di environment variable. Itu belum menjawab apakah secret pernah terlog, dibagikan, atau dirotasi.
Sudah pakai HTTPS. HTTPS penting, tetapi tidak menggantikan cookie flags, expiry policy, CSRF protection, atau rate limiting.
Token berbasis JWT dianggap otomatis aman. Format token bukan jaminan; penyimpanan, rotasi, expiry, dan invalidasi tetap penting.

Prinsip praktis: jika tim tidak bisa menjawab dengan jelas “kapan session berakhir, kapan token invalid, siapa yang bisa mengakses secret, dan bagaimana brute force dicegah”, kemungkinan ada security debt yang belum terlihat.

Area audit auth yang paling sering tertinggal

1. Session expiry terlalu longgar atau tidak konsisten

Masalah paling umum adalah session yang praktis tidak pernah berakhir. Kadang ada masa aktif absolut, tetapi tidak ada idle timeout. Kadang ada idle timeout, tetapi refresh token memperpanjang session tanpa batas. Di sistem lain, session browser dan session API punya aturan berbeda tanpa alasan yang jelas.

Risikonya:

Cookie atau token yang dicuri tetap bisa dipakai terlalu lama.
Akun tetap aktif di perangkat lama setelah logout “sebagian”.
Tidak ada batas kerusakan jika sebuah session terekspos.

Yang perlu dicek saat audit:

Apakah ada absolute expiration untuk session?
Apakah ada idle timeout yang masuk akal?
Apakah session diperpanjang setiap request tanpa batas?
Apakah logout menghapus session server-side, bukan hanya cookie client?
Apakah password reset atau perubahan email memaksa invalidasi session lama?

2. Cookie flag lemah

Pada aplikasi berbasis browser, cookie session yang tidak diberi atribut tepat memperbesar risiko pencurian dan penyalahgunaan. Tiga atribut yang paling sering salah atau diabaikan adalah:

HttpOnly: mencegah akses dari JavaScript dan mengurangi dampak XSS terhadap cookie.
Secure: memastikan cookie hanya dikirim melalui HTTPS.
SameSite: membantu membatasi pengiriman cookie lintas situs, berguna untuk mengurangi risiko CSRF.

Selain itu, perhatikan juga Domain dan Path. Scope cookie yang terlalu luas membuat lebih banyak subdomain atau endpoint ikut menerima cookie, padahal tidak perlu.

Gejala di produksi:

Cookie session terkirim ke subdomain yang tidak relevan.
Request lintas origin masih membawa cookie tanpa alasan yang jelas.
Insiden XSS kecil berubah menjadi pengambilalihan akun karena cookie dapat diakses script.

3. Token atau secret tidak pernah dirotasi

Secret yang dipakai untuk menandatangani token, API key internal, refresh token signing key, atau credential service account sering bertahan terlalu lama. Dalam jangka pendek ini nyaman, tetapi risikonya tinggi: jika secret pernah bocor ke log, dump konfigurasi, tiket support, atau backup lama, masa paparan menjadi panjang.

Audit harus menjawab:

Secret apa saja yang digunakan di auth?
Di mana secret disimpan?
Siapa yang dapat mengaksesnya?
Apakah ada prosedur rotasi tanpa downtime?
Apakah aplikasi bisa menerima lebih dari satu key saat masa transisi?

Rotasi tidak selalu berarti mengganti semuanya sekaligus. Praktik yang aman biasanya memakai fase transisi: terima key lama untuk verifikasi sementara, tetapi gunakan key baru untuk signing token baru sampai key lama benar-benar dihentikan.

4. Secret bocor di log dan observability

Banyak tim menyimpan body request login, header Authorization, cookie, atau nilai token ke log aplikasi karena ingin mudah debugging. Ini salah satu bentuk security debt yang sering dianggap sepele. Begitu secret masuk log, permukaan serangannya meluas ke sistem log, dashboard, alert, snapshot, dan akses tim lain.

Hal yang perlu diperiksa:

Apakah header sensitif dimasking sebelum logging?
Apakah payload login, refresh token, reset token, atau OTP tercatat?
Apakah stack trace pernah memuat environment variable?
Apakah APM, reverse proxy, atau WAF ikut menyalin header sensitif?

Kesalahan umum adalah menghapus logging di aplikasi utama, tetapi lupa bahwa load balancer, API gateway, atau error tracker masih menangkap data mentah.

5. Validasi input tidak konsisten

Endpoint auth sering berkembang bertahap: login web, login mobile, reset password, magic link, refresh token, change email, invite, SSO callback. Tanpa disiplin, setiap endpoint punya validasi sendiri, format error berbeda, dan perilaku yang tidak sejajar.

Contoh masalah nyata:

Endpoint reset password menerima identifier yang tidak dibatasi panjangnya, membuka peluang abuse atau biaya komputasi tinggi.
Validasi email berbeda antara registrasi dan login, memunculkan akun duplikat atau bypass.
Error message terlalu detail, memudahkan enumerasi akun.
Redirect URL pada flow login/SSO tidak divalidasi ketat, memicu open redirect.

Validasi yang konsisten bukan hanya soal UX. Ini mengurangi perbedaan perilaku yang bisa dipakai penyerang untuk memetakan sistem.

6. Rate limit absen di endpoint sensitif

Endpoint auth adalah target alami brute force, credential stuffing, OTP abuse, dan spam reset password. Tidak adanya rate limit adalah debt yang sering disadari terlambat karena traffic normal tetap terlihat baik.

Endpoint yang hampir selalu perlu pembatasan:

Login
Refresh token
Forgot password
Reset password
Verify OTP / MFA
Resend OTP atau magic link
Change email / change password

Rate limit tidak harus satu dimensi. Gabungkan beberapa sinyal:

Per IP
Per akun atau identifier
Per device fingerprint atau session
Per route sensitif

Trade-off-nya adalah risiko false positive untuk pengguna sah di jaringan bersama. Karena itu, limit perlu disertai observability dan jalur recovery yang jelas.

Checklist audit session dan secret yang praktis

Checklist berikut bisa dipakai untuk audit awal tanpa tooling yang rumit.

Checklist session

Semua session punya idle timeout dan absolute expiration.
Session ID diregenerasi setelah login dan setelah privilege change.
Logout menghapus session server-side, bukan hanya di client.
Perubahan password, email, atau MFA memicu invalidasi session aktif sesuai kebijakan.
Session store memiliki TTL yang benar dan tidak diperpanjang tanpa batas.
Tidak ada session test/staging yang hidup di production.
Cookie session diberi HttpOnly, Secure, dan SameSite yang sesuai.
Scope cookie dibatasi dengan Domain dan Path seperlunya.

Checklist token dan secret

Inventaris secret auth tersedia dan pemiliknya jelas.
Secret tidak hardcoded di kode sumber atau file contoh yang ikut terdeploy.
Secret dimasking di log, traces, dan error reports.
Ada prosedur rotasi yang terdokumentasi dan pernah diuji.
Refresh token atau signing key tidak hidup tanpa batas.
Token lama dapat dicabut atau dibuat tidak valid saat kondisi tertentu.
Backup, dump database, dan snapshot tidak menyimpan token mentah tanpa perlindungan.

Checklist endpoint sensitif

Login, forgot password, resend OTP, verify OTP, refresh token, dan reset password memiliki rate limit.
Response error tidak memudahkan enumerasi akun.
Input divalidasi dengan aturan yang konsisten lintas endpoint.
Redirect URL, callback URL, dan return URL di-allowlist, bukan hanya dicek pola string.
Audit log menyimpan kejadian keamanan penting tanpa menyimpan secret mentah.

Prioritas perbaikan berbasis risiko

Tidak semua debt harus diselesaikan sekaligus. Untuk auth, prioritaskan berdasarkan kombinasi dampak, kemungkinan dieksploitasi, dan biaya perbaikan.

Prioritas tinggi: dampak besar, perbaikan relatif cepat

Mengaktifkan HttpOnly dan Secure pada cookie session.
Mematikan logging untuk Authorization header, cookie, reset token, OTP, dan payload sensitif.
Menambahkan rate limit dasar pada login, forgot password, dan verify OTP.
Menetapkan TTL untuk session dan refresh token yang sebelumnya tidak terbatas.

Prioritas menengah: perlu koordinasi, tetap penting

Rotasi signing key dengan fase transisi.
Invalidasi session saat password diubah atau akun mengalami recovery.
Unifikasi validasi input di seluruh endpoint auth.
Normalisasi audit log keamanan agar cukup detail tanpa membocorkan secret.

Prioritas lebih kompleks: butuh perubahan arsitektur

Membangun revocation mechanism untuk token yang sebelumnya benar-benar stateless.
Memisahkan cookie scope lintas subdomain yang selama ini terlalu luas.
Migrasi secret ke secret manager terpusat jika sebelumnya tersebar di banyak sistem.

Jika tim kecil dan waktu terbatas, pilih item yang mengurangi blast radius terlebih dulu. Mengurangi umur session, menutup kebocoran log, dan membatasi brute force biasanya memberi hasil keamanan paling nyata tanpa rewrite besar.

Contoh gejala di produksi yang menandakan debt auth

Lonjakan percobaan login gagal dari banyak IP tanpa pemblokiran otomatis.
Banyak request refresh token dari device yang sudah seharusnya logout.
Session aktif tidak turun meski ada kebijakan logout massal atau password reset.
Header Authorization muncul di log aplikasi, gateway, atau tracing.
Tiket support tentang akun tiba-tiba keluar setelah sebagian hardening, menandakan sebelumnya mekanisme session tidak konsisten.
Rasio error verify OTP tinggi diikuti pola request berulang, tanda brute force atau abuse resend OTP.

Gejala ini penting karena security debt sering tidak muncul sebagai CVE yang jelas, melainkan sebagai pola perilaku yang “agak aneh” di telemetry.

Hardening bertahap tanpa rewrite besar

Pendekatan paling realistis adalah melakukan hardening bertahap, dimulai dari kontrol yang dapat ditambahkan di pinggir sistem terlebih dulu.

Tahap 1: Tutup paparan paling jelas

Masking atau drop header dan field sensitif dari log.
Aktifkan cookie flags yang sesuai.
Tambahkan rate limit dasar pada endpoint sensitif.
Tetapkan TTL yang eksplisit untuk session, refresh token, dan reset token.

Langkah-langkah ini sering bisa dilakukan di middleware, reverse proxy, atau konfigurasi framework tanpa mengubah alur bisnis utama.

Tahap 2: Rapikan lifecycle session dan token

Regenerasi session ID setelah login.
Invalidasi session saat privilege berubah.
Pastikan logout menghapus state server-side.
Pisahkan absolute expiration dan idle timeout.

Poin pentingnya adalah membuat lifecycle bisa dijelaskan dengan jelas: kapan dibuat, kapan diperpanjang, kapan dicabut, dan kapan berakhir otomatis.

Tahap 3: Siapkan rotasi secret

Inventaris semua secret auth.
Tambahkan dukungan multi-key untuk masa transisi jika memungkinkan.
Uji rotasi di staging dengan prosedur rollback.
Tentukan jadwal rotasi periodik dan rotasi darurat saat insiden.

Rotasi yang aman membutuhkan operasi yang dapat diulang, bukan aksi manual sekali pakai.

Tahap 4: Standarkan validasi dan observability

Buat utilitas validasi bersama untuk endpoint auth.
Samakan pola error agar tidak membocorkan keberadaan akun.
Tambahkan event audit untuk login sukses, login gagal, reset password, perubahan secret, dan revoke session.
Pastikan observability menyimpan metadata yang cukup tanpa nilai sensitif.

Contoh implementasi generik backend

Berikut contoh pseudocode generik yang menunjukkan beberapa kontrol dasar pada endpoint login. Contohnya sengaja dibuat netral terhadap framework.

// middleware log sanitization
function sanitizeRequestForLogging(req) {
  return {
    method: req.method,
    path: req.path,
    ip: req.ip,
    headers: {
      ...req.headers,
      authorization: req.headers.authorization ? "[REDACTED]" : undefined,
      cookie: req.headers.cookie ? "[REDACTED]" : undefined
    },
    body: {
      ...req.body,
      password: req.body.password ? "[REDACTED]" : undefined,
      otp: req.body.otp ? "[REDACTED]" : undefined,
      token: req.body.token ? "[REDACTED]" : undefined
    }
  }
}

// login handler
async function login(req, res) {
  enforceRateLimit({
    key: `login:ip:${req.ip}`,
    windowSeconds: 60,
    maxRequests: 10
  })

  const email = normalizeEmail(req.body.email)
  const password = req.body.password

  validateLoginInput({ email, password })

  const user = await userStore.findByEmail(email)
  const valid = user && await passwordHasher.verify(password, user.passwordHash)

  if (!valid) {
    auditLog("auth.login_failed", {
      ip: req.ip,
      emailHash: hashForAudit(email)
    })
    return res.status(401).json({ message: "Kredensial tidak valid" })
  }

  const session = await sessionStore.create({
    userId: user.id,
    createdAt: now(),
    expiresAt: nowPlusHours(12),
    idleTimeoutSeconds: 1800
  })

  res.setCookie("session", session.id, {
    httpOnly: true,
    secure: true,
    sameSite: "Lax",
    path: "/",
    // domain disetel sesempit mungkin
  })

  auditLog("auth.login_success", {
    userId: user.id,
    ip: req.ip,
    sessionIdHash: hashForAudit(session.id)
  })

  return res.json({ ok: true })
}

Kenapa pendekatan ini bekerja:

Sanitasi log menurunkan risiko kebocoran horizontal ke sistem observability.
Rate limit mengurangi brute force murah yang sering lolos pada sistem lama.
Validasi terpusat mencegah perbedaan perilaku antar endpoint.
TTL eksplisit membuat session lifecycle dapat diuji dan dipantau.
Cookie flags mengurangi peluang penyalahgunaan di browser.

Untuk rotasi secret, pola generik yang sering dipakai adalah memisahkan key untuk signing dan daftar key untuk verification.

function signToken(payload) {
  return tokenSigner.sign(payload, activeSigningKey)
}

function verifyToken(token) {
  for (const key of verificationKeys) {
    const result = tokenSigner.tryVerify(token, key)
    if (result.valid) return result.payload
  }
  throw new Error("Token tidak valid")
}

Dengan pola ini, token baru ditandatangani menggunakan key aktif, sementara token lama masih bisa diverifikasi selama masa transisi. Setelah semua token lama lewat masa berlakunya, key lama dapat dihapus dari daftar verifikasi.

Metrik yang perlu dipantau

Hardening auth tanpa metrik akan sulit dievaluasi. Pantau indikator berikut:

Login success rate dan login failure rate.
Rate limited requests per endpoint sensitif.
Jumlah session aktif dan distribusi usia session.
Refresh token usage rate serta anomali per device atau per akun.
Jumlah logout vs revoke session.
Password reset requests per akun dan per IP.
OTP verify failures dan resend OTP frequency.
Jumlah event yang mengandung field sensitif setelah sanitasi log diterapkan.

Yang penting bukan hanya mengumpulkan metrik, tetapi memahami baseline. Tanpa baseline, tim sulit membedakan dampak hardening yang sehat dari bug yang memutus flow login pengguna sah.

Kesalahan umum saat tim merasa sistem “masih aman”

Menyamakan tidak ada insiden dengan tidak ada risiko. Banyak masalah auth baru terlihat setelah data pendukung tersedia.
Mengandalkan satu kontrol. Misalnya merasa HTTPS cukup tanpa cookie flags dan session expiry yang baik.
Takut menambah TTL atau rate limit karena UX. Trade-off memang ada, tetapi bisa diukur dan disesuaikan. Tidak menerapkan apa pun biasanya lebih buruk.
Menyimpan token mentah untuk debugging. Ini memindahkan risiko, bukan menyelesaikannya.
Membiarkan secret berumur panjang karena takut rotasi. Semakin lama ditunda, semakin tinggi biaya dan risiko saat insiden.
Menganggap validasi input urusan business logic saja. Pada auth, konsistensi validasi adalah bagian dari hardening.

Penutup

Security debt di auth sering datang dari hal-hal yang tampak kecil dan tertinggal: session yang terlalu lama, cookie yang terlalu longgar, token yang tak pernah dirotasi, secret yang diam-diam masuk log, dan endpoint sensitif tanpa rate limit. Masalah-masalah ini sering tidak bisa dibuktikan dampaknya hari ini, tetapi tetap penting karena menentukan seberapa besar kerusakan saat sesuatu salah.

Audit yang baik seharusnya menghasilkan dua hal: daftar kontrol yang bisa diverifikasi dan rencana perbaikan bertahap berbasis risiko. Jika tim belum siap melakukan redesign auth besar, mulai dari yang paling murah dan paling menurunkan blast radius: sanitasi log, cookie flags, TTL session yang jelas, dan rate limit di endpoint sensitif. Itu bukan solusi sempurna, tetapi jauh lebih baik daripada merasa sistem masih aman tanpa bukti yang bisa diuji.

Quick Search

shopping_cart Keranjang