Checklist hardening review code AI untuk auth dan abuse prevention berguna saat tim mulai menerima banyak kode yang tampak produktif tetapi lolos dari review keamanan dasar. Masalahnya bukan hanya bug fungsional, melainkan pola implementasi yang terlihat meyakinkan namun menyisakan celah: token terlalu permisif, session tidak diputar, upload file tidak dibatasi, atau endpoint publik tidak punya perlindungan abuse.

Dalam konteks tren cleaning up after AI rockstar developers, inti persoalannya adalah ini: kode yang selesai cepat sering terlihat rapi, lolos happy path, dan bahkan disertai test dasar, tetapi tidak otomatis aman. Artikel ini memberi checklist review yang bisa dipakai tim engineering untuk memeriksa area backend yang paling sering bocor sebelum merge dan sebelum rilis.

Prinsip review: cari asumsi diam-diam, bukan hanya bug yang terlihat

Saat mereview kode hasil AI atau developer yang bergerak terlalu cepat, red flag paling umum adalah asumsi implisit yang tidak pernah ditulis sebagai requirement. Contohnya:

  • "Endpoint ini hanya dipakai internal" tetapi sebenarnya bisa diakses publik.
  • "Frontend pasti mengirim field yang benar" sehingga backend tidak memvalidasi ulang.
  • "JWT sudah cukup" tanpa evaluasi masa berlaku, rotasi, dan pencabutan token.
  • "Upload hanya gambar" padahal server tidak memverifikasi tipe file secara aman.
  • "Rate limit ada di gateway" tetapi endpoint sensitif juga perlu proteksi di level aplikasi.

Review yang baik tidak berhenti pada pertanyaan "apakah fitur ini jalan?" tetapi lanjut ke:

  • Siapa yang boleh memanggil endpoint ini?
  • Apa yang terjadi jika input sengaja dimanipulasi?
  • Apakah penyerang bisa mengulang request ribuan kali?
  • Apakah log, error, atau response membocorkan informasi sensitif?
  • Apakah ada jalur bypass untuk role, tenancy, atau batasan file?

Checklist review auth dan session

1. Pastikan kontrol autentikasi dan otorisasi dipisah dengan jelas

Red flag yang sering muncul adalah endpoint hanya memeriksa apakah user login, tetapi tidak memeriksa apakah user berhak melakukan aksi tersebut. Ini umum terjadi pada endpoint admin, endpoint lintas tenant, dan operasi yang mengubah data sensitif.

Implementasi buruk: middleware hanya mengecek keberadaan session atau token, lalu handler langsung mengubah resource berdasarkan parameter ID.

// Buruk: hanya cek login, tidak cek kepemilikan atau role
app.post('/users/:id/disable', requireAuth, async (req, res) => {
  await userService.disable(req.params.id)
  res.sendStatus(204)
})

Lebih aman: validasi role, scope, dan kepemilikan resource secara eksplisit.

// Lebih aman: cek izin spesifik sebelum aksi sensitif
app.post('/users/:id/disable', requireAuth, requirePermission('user:disable'), async (req, res) => {
  if (!canManageUser(req.user, req.params.id)) {
    return res.sendStatus(403)
  }

  await userService.disable(req.params.id)
  res.sendStatus(204)
})

Mengapa ini penting: banyak kode AI menghasilkan pola CRUD yang seragam, tetapi authorization jarang benar jika tidak diarahkan secara spesifik. Review harus memeriksa setiap endpoint mutasi: apakah hanya autentikasi, atau juga ada otorisasi yang tepat?

2. Review lifecycle session dan token

Untuk cookie session maupun token, cek hal-hal berikut:

  • Session dirotasi setelah login dan perubahan privilege untuk mencegah fixation.
  • Cookie sensitif memakai HttpOnly, Secure, dan SameSite yang sesuai.
  • JWT atau access token memiliki masa berlaku masuk akal, tidak terlalu panjang.
  • Refresh token dapat dicabut dan tidak disimpan sembarangan.
  • Logout benar-benar menginvalidasi session server-side bila arsitekturnya mendukung.

Red flag umum:

  • Token berlaku sangat lama tanpa alasan jelas.
  • Secret signing hardcoded di source code.
  • Session ID tidak diputar setelah login.
  • Cookie auth dikirim tanpa atribut keamanan yang layak.
  • Response login memberi error yang terlalu detail, misalnya membedakan akun tidak ada vs password salah.

Catatan: membedakan error login dapat membantu UX, tetapi juga mempermudah enumerasi akun. Untuk endpoint publik, lebih aman gunakan pesan generik dan log detail di sisi server.

3. Cek reset password, magic link, dan OTP

Area ini sering lolos review karena bukan bagian utama login, padahal sering menjadi pintu masuk akun. Verifikasi:

  • Token reset bersifat satu kali pakai.
  • Token memiliki masa berlaku pendek.
  • Permintaan reset tidak mengungkap apakah email terdaftar.
  • OTP dibatasi percobaan dan diberi cooldown.
  • Magic link terikat ke konteks yang sesuai bila diperlukan, misalnya device atau nonce.

Checklist secret handling dan konfigurasi sensitif

1. Jangan percaya pada "nanti dipindah ke env"

Kode hasil AI sering menaruh API key, credential, atau signing secret langsung di contoh implementasi. Bahayanya bukan hanya kebocoran repo, tetapi juga kebiasaan menyalin pola itu ke produksi.

Periksa:

  • Tidak ada secret hardcoded di source code, test fixture, atau contoh config.
  • Secret tidak ditulis ke log, error, atau telemetry.
  • Environment variable bukan satu-satunya kontrol; akses ke secret store dan rotasi juga dipikirkan.
  • Credential berbeda untuk dev, staging, dan production.

Implementasi buruk:

const jwtSecret = 'super-secret-key'
const storageKey = 'prod-access-key'

Lebih aman:

const jwtSecret = process.env.JWT_SECRET
if (!jwtSecret) {
  throw new Error('JWT_SECRET is required')
}

Tambahkan review berikut:

  • Apakah aplikasi gagal start jika secret wajib tidak tersedia?
  • Apakah ada fallback default yang berbahaya?
  • Apakah konfigurasi debug mengaktifkan output sensitif?

2. Audit log dan observability

Sanitasi log adalah bagian dari hardening. Banyak insiden bukan karena autentikasi gagal, tetapi karena token, cookie, atau header otorisasi tertulis ke log aplikasi, reverse proxy, atau error tracking.

Checklist cepat:

  • Masking untuk password, token, API key, dan cookie.
  • Jangan log request body penuh untuk endpoint auth atau upload.
  • Pastikan stack trace tidak dikirim mentah ke client.
  • Gunakan correlation ID tanpa membocorkan data sensitif.

Checklist input validation dan data boundary

1. Validasi di boundary server, bukan hanya di frontend

Frontend validation membantu UX, tetapi bukan kontrol keamanan. Untuk setiap endpoint, review:

  • Schema request jelas dan ketat.
  • Field tak dikenal ditolak atau diabaikan secara sadar.
  • Tipe data, panjang, enum, dan format diverifikasi.
  • Normalisasi input dilakukan konsisten, misalnya email lowercase jika memang dibutuhkan.
  • Query parameter untuk sorting, filtering, dan pagination dibatasi.

Red flag:

  • Menggunakan request body langsung ke ORM update tanpa allowlist field.
  • Menerima object bebas untuk filter database.
  • Parameter numerik tidak dibatasi sehingga memicu beban besar.
  • Pencarian memakai regex atau wildcard tak terkendali dari user.

Implementasi buruk:

// Buruk: mass assignment dan field liar bisa lolos
await db.user.update({
  where: { id: req.user.id },
  data: req.body
})

Lebih aman:

// Lebih aman: pilih field yang memang boleh diubah
const payload = {
  displayName: req.body.displayName,
  timezone: req.body.timezone
}

validateProfileUpdate(payload)
await db.user.update({ where: { id: req.user.id }, data: payload })

Mengapa ini bekerja: allowlist memaksa developer menentukan boundary data yang jelas. Ini mencegah field sensitif seperti role, status verifikasi, atau quota ikut terubah hanya karena terkirim di body.

2. Validasi output juga penting

Review keamanan tidak hanya soal input. Pastikan response API tidak mengembalikan field internal seperti:

  • Hash password.
  • Secret internal.
  • Token refresh.
  • Flag keamanan internal.
  • Metadata yang mempermudah enumerasi atau abuse.

Kesalahan umum: langsung mengembalikan object model penuh dari database setelah insert atau update.

Checklist file upload yang sering diabaikan

Endpoint upload hampir selalu termasuk area berisiko tinggi. Jika tim menerima kode dari AI, anggap upload sebagai titik audit wajib.

1. Verifikasi tipe file secara nyata, bukan hanya nama file

Jangan percaya pada ekstensi atau header Content-Type dari client. Minimal, periksa signature file atau gunakan library parser yang sesuai. Batasi tipe file yang benar-benar diperlukan.

Checklist upload:

  • Allowlist tipe file yang diizinkan.
  • Batas ukuran file dan jumlah file per request.
  • Nama file disanitasi dan tidak dipakai langsung sebagai path.
  • Penyimpanan menggunakan nama acak atau ID internal.
  • File tidak dieksekusi sebagai script oleh server web.
  • Jika file dipublikasikan, pertimbangkan domain atau bucket terpisah.

2. Cegah path traversal dan overwrite

Implementasi buruk:

// Buruk: nama file dari user dipakai langsung
const filePath = `/uploads/${req.body.filename}`
await saveFile(filePath, req.file.buffer)

Lebih aman:

// Lebih aman: abaikan nama file asli untuk path penyimpanan
const fileId = generateOpaqueId()
const safeExtension = detectAllowedExtension(req.file.buffer)
const filePath = `/uploads/${fileId}.${safeExtension}`
await saveFile(filePath, req.file.buffer)

Ini mencegah traversal, overwrite, dan kebocoran struktur filesystem. Bila aplikasi memproses gambar, pertimbangkan re-encode file untuk mengurangi metadata berbahaya atau payload yang tidak diharapkan.

3. Audit endpoint upload sebagai target abuse

Upload sering dipakai untuk:

  • Menghabiskan storage.
  • Mengirim file sangat besar atau banyak.
  • Mencoba file parser crash.
  • Menyisipkan konten berbahaya yang nanti disajikan kembali.

Karena itu, endpoint upload perlu rate limiting, authentication sesuai kebutuhan, dan observability yang memadai.

Checklist rate limiting dan abuse prevention

1. Tentukan endpoint yang wajib punya proteksi abuse

Tidak semua endpoint butuh kebijakan yang sama. Yang hampir selalu perlu perhatian khusus:

  • Login, reset password, OTP, magic link.
  • Register dan invite.
  • Search, export, dan report generation.
  • Upload file.
  • Endpoint publik yang memicu query berat atau biaya eksternal.
  • Admin action yang sensitif.

Red flag umum pada kode cepat:

  • Rate limiting hanya di satu endpoint login, padahal reset password dan OTP dibiarkan terbuka.
  • Limit hanya berbasis IP, padahal abuse bisa menyebar lewat banyak IP.
  • Tidak ada proteksi per akun, per API key, atau per tenant.
  • Tidak ada timeout dan concurrency control untuk operasi mahal.

2. Gunakan kombinasi identitas limiter

Rate limiting yang efektif biasanya memakai kombinasi kunci, tergantung konteks:

  • Per IP untuk endpoint publik anonim.
  • Per akun atau user ID setelah login.
  • Per API key untuk integrasi pihak ketiga.
  • Per tenant untuk sistem multi-tenant.
  • Per route atau kategori aksi untuk operasi sensitif.

Alasannya: satu dimensi limiter mudah dibypass atau justru terlalu agresif. Misalnya, limiter per IP saja dapat memukul banyak user di belakang NAT, tetapi limiter per akun saja tidak cukup untuk endpoint anonim.

3. Bedakan rate limiting, throttling, quota, dan concurrency control

  • Rate limiting: membatasi jumlah request dalam rentang waktu.
  • Throttling: memperlambat atau menolak saat intensitas tinggi.
  • Quota: batas penggunaan jangka lebih panjang, misalnya harian.
  • Concurrency control: membatasi jumlah job atau operasi paralel.

Untuk abuse prevention, tim sering terlalu fokus pada rate limiting dan lupa concurrency control. Padahal satu user dapat mengirim sedikit request, tetapi tiap request memicu pekerjaan berat yang menumpuk di database, worker, atau layanan eksternal.

4. Response error jangan membantu penyerang

Jika limiter aktif, response sebaiknya cukup informatif untuk klien sah, tetapi tidak membocorkan terlalu banyak detail internal. Pastikan juga event dibawa ke monitoring agar tim bisa melihat pola abuse, bukan hanya menolak request secara diam-diam.

Checklist verifikasi per area: API publik, admin panel, dan endpoint upload

Verifikasi untuk API publik

  • Apakah semua endpoint publik punya schema validation yang ketat?
  • Apakah pagination dibatasi dengan maksimum yang masuk akal?
  • Apakah ada rate limiting per IP dan, jika relevan, per API key?
  • Apakah error response menghindari enumerasi user atau resource?
  • Apakah CORS, method yang diizinkan, dan auth boundary sudah jelas?
  • Apakah endpoint search/filter bisa memicu query mahal atau wildcard tak terbatas?
  • Apakah data sensitif tersembunyi dari response default?

Verifikasi untuk admin panel

  • Apakah akses admin dipisah jelas dari user biasa?
  • Apakah role/permission dicek di server untuk setiap aksi, bukan hanya menu UI?
  • Apakah operasi sensitif memerlukan re-auth atau step-up auth jika dibutuhkan?
  • Apakah semua aksi admin tercatat di audit log?
  • Apakah endpoint admin tetap punya proteksi CSRF bila berbasis cookie session?
  • Apakah fitur export, impersonation, atau bulk action dibatasi dan diawasi?

Verifikasi untuk endpoint upload

  • Apakah tipe file diverifikasi selain dari ekstensi?
  • Apakah ukuran file, jumlah file, dan timeout request dibatasi?
  • Apakah nama file internal dihasilkan server?
  • Apakah file publik disajikan dari lokasi yang aman dan tidak executable?
  • Apakah metadata atau konten file dipindai jika risiko bisnis mengharuskan?
  • Apakah upload dilindungi rate limiting dan, bila perlu, quota per user/tenant?

Red flag yang sering muncul pada kode hasil AI

  • Middleware auth ada, tetapi tidak semua route sensitif memakainya.
  • Authorization diasumsikan oleh frontend atau naming route.
  • Secret hardcoded atau fallback ke nilai default.
  • Validasi hanya memeriksa field wajib, bukan range, enum, atau field liar.
  • Mass assignment ke ORM.
  • Upload menerima semua file lalu memeriksa belakangan.
  • Login dibatasi, tetapi forgot password atau OTP tidak.
  • Log menyimpan header Authorization, cookie, atau request body sensitif.
  • Endpoint admin tersembunyi di UI, tetapi tidak terlindungi di backend.
  • Error terlalu detail untuk endpoint publik.

Pola-pola ini berbahaya karena terlihat "masuk akal" saat dibaca cepat. Review harus dilakukan dengan mindset adversarial: jika saya mencoba menyalahgunakan endpoint ini, apa jalur termudahnya?

Langkah audit sebelum merge

Gunakan daftar berikut sebagai gate ringan namun tegas untuk pull request yang menyentuh auth atau endpoint publik:

  1. Petakan boundary akses: endpoint ini publik, authenticated, admin, atau internal?
  2. Review auth dan authorization: siapa boleh melakukan apa, di level route dan resource.
  3. Cek input/output schema: apa yang diterima, apa yang dikembalikan, field apa yang harus disembunyikan.
  4. Periksa abuse path: bisa di-spam, di-enumerasi, atau memicu kerja mahal?
  5. Audit secret dan logging: adakah kebocoran credential, token, atau data sensitif?
  6. Uji negative path: token invalid, role kurang, file terlalu besar, payload liar, pagination ekstrem.
  7. Pastikan observability: ada log keamanan yang cukup tanpa membocorkan rahasia.

Praktik yang membantu: minta reviewer kedua khusus untuk area security-sensitive, meski review singkat. Banyak celah auth lolos karena reviewer utama fokus pada logika bisnis.

Langkah audit sebelum rilis

Sebelum deploy, lakukan verifikasi lintas endpoint, bukan hanya per PR. Tujuannya memastikan kombinasi perubahan tidak membuka jalur baru.

  1. Enumerasi endpoint sensitif: login, reset password, admin, upload, export, search berat.
  2. Uji dengan akun berbeda: anonymous, user biasa, admin, tenant lain.
  3. Simulasikan abuse ringan: burst request, upload besar, pagination maksimum, percobaan login berulang.
  4. Review config runtime: cookie flags, origin yang diizinkan, secret wajib, mode debug mati.
  5. Periksa dashboard dan alert: apakah 401/403/429, lonjakan upload, atau kegagalan auth terlihat jelas?
  6. Audit rollback dan kill switch: bisa menonaktifkan endpoint berisiko atau memperketat limiter dengan cepat?

Jika tim punya staging, gunakan untuk menguji perilaku limiter dan upload. Jika tidak, setidaknya lakukan smoke test aman di lingkungan yang merepresentasikan konfigurasi produksi.

Penutup

Checklist hardening review code AI untuk auth dan abuse prevention bukan tentang curiga pada AI semata, melainkan tentang menerima kenyataan bahwa kode yang dibuat sangat cepat cenderung menyembunyikan asumsi berbahaya. Tim yang disiplin pada auth, session, secret handling, input validation, file upload, rate limiting, dan abuse prevention akan menangkap celah yang tidak terlihat pada happy path.

Jika ingin membuat proses ini efektif, jangan jadikan checklist sebagai formalitas. Tempelkan ke template PR, tandai endpoint sensitif, dan biasakan reviewer bertanya: bagaimana fitur ini bisa disalahgunakan? Pertanyaan itu biasanya jauh lebih bernilai daripada sekadar memastikan responsnya 200 OK.