Menghapus module atau kode lama memang bisa terasa seperti momen pembersihan ringan, tetapi seperti cerita “I Deleted 200 Lines...“ menunjukkan, itu juga peluang audit. Pada primernya, Audit Auth saat kode lama dihapus berarti memastikan flow session, secret, dan rate limit tetap aman dan konsisten sebelum perubahan benar-benar dipakai.

Langsung jawab: setiap perubahan yang menghilangkan login atau session logic lama harus disertai verifikasi flow otentikasi end-to-end, invalidasi session yang tidak lagi berlaku, validasi secret atau credential yang tersisa, pengawasan upload/abuse, serta mekanisme rate limit yang masih memadai. Tanpa langkah ini, hardening bisa hilang justru saat kode disederhanakan.

Mengapa Cleanup Auth/Session Penting dalam Code Removal

Penghapusan kode lama sering kali meninggalkan fragmen autentikasi yang tidak aktif tapi masih dapat diakses, seperti token yang tidak direvok atau secret yang tidak diganti. Secara ringan, ini menambah attack surface. Cleanup mengurangi risiko berikut:

  • Token/Session stale yang tidak otomatis invalidasi setelah route/handler dihapus.
  • Secret configurasi yang masih tersimpan di file lama walau prosesnya sudah berpindah.
  • Rate limit yang disetting berdasarkan modul lama sehingga tidak lagi relevan.

Jadi audit ini bukan hanya soal keamanan, tetapi menjaga konsistensi behavior aplikasi dan menghindari regressions ketika kode dihapus.

Checklist Audit Saat Menghapus Module Auth Lama

Audit ini meliputi lima area utama. Setiap area berisi pemeriksaan dan contoh langkah konkret.

1. Flow Autentikasi

Pastikan tidak ada access path tersisa yang melewati state lama. Langkah praktikal:

  • Telusuri route, middleware, dan guard yang still dipakai vs yang dihapus.
  • Verifikasi panggilan login/logout/kepemilikan token terkini, misalnya dengan regression test yang coba akses API menggunakan credential lama dan baru.
  • Perbarui dokumentasi flow jika endpoint path digabung atau dibuang.

Contoh pseudocode validasi flow:

function authenticate(request) {
  const sessionId = request.cookies['session'];
  if (!sessionId) return reject('Unauthenticated');
  const session = sessionStore.get(sessionId);
  if (!session || session.revoked) return reject('Session invalid');
  if (session.source === 'legacy') {
    // Pastikan legacy route sudah dihapus dari router
    log('Legacy session hit, verify removal');
  }
  return session.user;
}

2. Invalidasi Session dan Token

Masalah umum: saat module lama dihapus, session factory lama tidak lagi dijalankan, sehingga token yang dikeluarkan sebelumnya tidak otomatis dicabut.

  • Cek mass logout (all tokens) ketika removing handler: misalnya dengan menambah migration yang menandai session table sebagai revoked.
  • Implementasikan hook cleanup di background job jika session tetap aktif.
  • Gunakan monitoring untuk memastikan rata-rata waktu hidup session tidak naik setelah perubahan.

Contoh langkah konkret:

db.sessions.updateMany({ source: 'legacy' }, { $set: { revoked: true } });
cache.publish('invalidate-session', { source: 'legacy' });

3. Penanganan Secret & Credential

Secret yang pernah dipakai oleh kode lama bisa tersimpan di environment variable, config file, atau pipeline CI. Setiap penghapusan module harus dibarengi dengan audit secret:

  • Gunakan tools seperti secret scanning (misal git secrets) untuk memastikan tidak ada API keys tertinggal.
  • Jika module lama memegang credential khusus, rotasi secret tersebut dan cek dependensi baru sudah memakai secret yang benar.
  • Log perubahan secret ke vault access audit sehingga ada jejak perubahan.

Contoh: jika modul lama memperluas token signing key, buat migration yang menetapkan secret baru:

const newSecret = keyManager.rotate('auth-session');
config.set('jwt.secret', newSecret);
auditLog('Secret rotated due to auth module removal.');

4. Validasi Upload & Input Baru

Bila kode lama memfilter upload file/parameters tertentu, penghapusannya bisa menimbulkan lubang validasi. Lakukan:

  • Review middleware upload (misal size limit, content type) dan pastikan versi baru tetap dipasang.
  • Tulis test yang menyimulasikan upload dengan payload yang dulu ditolak.
  • Perhatikan endpoint yang sebelumnya hanya bisa diakses setelah login dihapus—pastikan guard lain masih ada.

Contoh konfigurasi upload di Express dengan middleware global:

app.post('/upload', uploadLimiter, authGuard, multer({
  limits: { fileSize: 5 * 1024 * 1024 },
  fileFilter: (req, file, cb) => {
    cb(null, /image\/.*/.test(file.mimetype));
  }
}).single('file'), handler);

5. Rate Limit dan Pencegahan Abuse

Hapus module dan rate limit default bisa berubah. Pastikan:

  • Rate limit berbasis user/IP masih terpasang untuk endpoint kritikal.
  • Gunakan counter yang disinkronisasi dengan cache Redis atau database, jangan hanya mematikan middleware lama.
  • Rekalibrasi threshold jika modul sebelumnya memaksa limit lebih rendah.

Contoh konfigurasi rate limit sederhana:

rateLimiter.init({
  windowMs: 60 * 1000,
  max: 30,
  keyGenerator: (req) => req.user?.id || req.ip,
  handler: (req, res) => res.status(429).send('Rate limit exceeded.')
});
app.use('/protected-route', rateLimiter.middleware);

Pendekatan Validasi dan Monitoring Setelah Perubahan

Setelah membersihkan kode, lakukan validasi berikut:

  • Regression tests: jalankan suite otentikasi, termasuk simulasi login/token invalid.
  • Security smoke test: jalankan fuzzing terhadap endpoint yang berubah.
  • Monitoring produksi: buat alert jika terjadi spike login failure, session expiry error, atau rate limit hit secara abnormal.

Tambahkan metrics seperti auth_success_rate, session_revocations, atau rate_limit_blocks ke dashboard agar perubahan cepat terdeteksi.

Debugging tip: gunakan log correlation ID di semua lapisan otentikasi agar cleanup dapat dilacak jika pengguna masih mengakses session lama.

Kesimpulan

Audit Auth saat kode lama dihapus berarti memastikan session, secret, upload, dan rate limit tetap konsisten serta terukur. Checklist praktis di atas (flow autentikasi, invalidasi session, secret handling, upload validation, rate limit) membantu menjaga security hardening. Setelah cleanup, kombinasikan regression test dengan monitoring untuk memastikan tidak ada celah baru muncul.