Security checklist adalah daftar hal yang harus benar sebelum aplikasi naik ke production. Bayangin pilot sebelum terbang: walau sudah ribuan jam di udara, dia tetap membaca checklist pre-flight satu per satu. Bukan karena lupa caranya, tapi karena kesalahan paling berbahaya justru hal yang kamu "tahu" lalu kelewat di saat yang salah. Checklist deploy bekerja sama: tiap baris dicek, gak ada yang dianggap "pasti udah".
🧪 Tebakan cepat: sebuah aplikasi HTTPS-nya mati dan password-nya di-hash pakai sha1, sisanya aman. Berapa skornya di
securityAudit: 25, 50, atau 70? Tebak dulu, jawabannya ada di bagian "Checklist jadi kode: securityAudit".
Isi checklist sebelum deploy
Hampir semua baris di checklist ini sudah kamu pelajari di jalur keamanan. Di sini semuanya dikumpulkan jadi satu daftar:
| Area | Yang dicek | Pelajarannya |
|---|---|---|
| Login | password di-hash bcrypt atau Argon2 | Password Hashing & Storage |
| Login | cookie session HttpOnly, Secure, SameSite |
Cookie Security |
| Login | rate limit di endpoint login | Rate Limiting & Throttling |
| Login | 2FA, minimal untuk akun admin | pelajaran ini, di bawah |
| Akses | tiap endpoint sensitif mengecek otorisasi di server | OWASP Top 10 |
| Input | semua input divalidasi di server | Input Validation & Schema |
| Input | query pakai parameter, bukan string disambung | SQL Injection Prevention |
| Output | output di-escape sesuai konteks | XSS Prevention & Sanitization |
| Form | CSRF protection aktif | CSRF (Cross-Site Request Forgery) |
| HTTP | HTTPS di mana-mana, plus HSTS | HTTPS & TLS Basics |
| HTTP | security headers (CSP, nosniff, frame-ancestors) | Security Headers Lengkap |
| HTTP | CORS cuma mengizinkan origin yang jelas, bukan * |
CORS Deep Dive |
| Server | APP_DEBUG=false, pesan error umum |
Sensitive Data Exposure |
| Secret | .env gak di-commit, secret di secret manager |
Environment Variables & Secrets |
| Dependency | npm audit atau composer audit bersih |
Dependency Vulnerabilities |
| Operasional | backup sudah dicoba restore, monitoring dan alert nyala | Security Logging & Monitoring |
Checklist jadi kode: securityAudit
Checklist di kertas gampang di-centang tanpa dicek. Lebih aman kalau sebagian dicek oleh kode. Di latihan, kamu bikin fungsi securityAudit(config) yang menilai lima baris checklist dari object konfigurasi, mulai dari skor 100:
| Kalau | Kurangi | Issue |
|---|---|---|
https false |
25 | "HTTPS not enabled" |
debug true |
20 | "Debug mode is on" |
csrfProtection false |
20 | "CSRF protection disabled" |
passwordHashing bukan "bcrypt" atau "argon2" |
25 | "Weak password hashing" |
corsOrigin sama dengan "*" |
10 | "CORS wildcard origin" |
function securityAudit(config) {
let score = 100;
const issues = [];
if (!config.https) { score -= 25; issues.push("HTTPS not enabled"); }
if (config.debug) { score -= 20; issues.push("Debug mode is on"); }
if (!config.csrfProtection) { score -= 20; issues.push("CSRF protection disabled"); }
if (config.passwordHashing !== "bcrypt" && config.passwordHashing !== "argon2") {
score -= 25;
issues.push("Weak password hashing");
}
if (config.corsOrigin === "*") { score -= 10; issues.push("CORS wildcard origin"); }
return { score: Math.max(0, score), issues };
}
- Lima
ifterpisah, bukanelse if: satu aplikasi bisa punya lima masalah sekaligus, dan semuanya harus tercatat. - Hashing dicek pakai allowlist: yang lolos cuma
"bcrypt"dan"argon2". Jadi"md5","sha1", dan"plain"sama-sama dihitung lemah. Math.max(0, score)menjaga skor gak turun di bawah 0.
Ini hasilnya pada empat konfigurasi yang dipakai latihan (Lab memakai fungsi yang sama):
| Konfigurasi | Masalah | Hasil |
|---|---|---|
semua aman, bcrypt, CORS https://myapp.com |
tidak ada | { score: 100, issues: [] } |
HTTPS mati, debug nyala, CSRF mati, md5, CORS * |
lima-limanya | skor 0 |
semua aman, argon2, CORS * |
CORS | skor 90 |
| HTTPS mati, sha1, sisanya aman | HTTPS, hashing | skor 50 |
HTTPS mati (kurangi 25) dan sha1 (kurangi 25) bikin 100 jadi 50. Itu jawaban tebakannya.
Password, 2FA, dan "never trust user input"
- Never trust user input: semua yang datang dari luar sistem (form, URL, header, cookie, file) dianggap belum aman sampai divalidasi di server. Hampir separuh baris checklist di atas turunan dari prinsip ini.
- Panjang password: panduan NIST SP 800-63B meminta minimal 8 karakter. Revisi terbarunya (SP 800-63B-4) menaikkan jadi 15 karakter kalau password adalah satu-satunya faktor login, dan tetap 8 kalau dipakai bareng faktor kedua. Panjang lebih penting daripada aturan "wajib simbol", dan password yang pernah bocor sebaiknya ditolak.
- 2FA (two-factor authentication) menambah faktor kedua selain password: kode OTP dari aplikasi authenticator, passkey, atau kunci fisik. Password yang bocor saja gak cukup buat masuk. Kalau faktornya dua atau lebih, namanya juga MFA.
⚠️ Jebakan yang sering ketemu
- Pakai blocklist untuk hashing. Cek
=== "md5" || === "sha1"bikin"plain"lolos sebagai "aman". Cek yang boleh (bcrypt, argon2), bukan yang dilarang. else ifdi audit. Begitu satu masalah ketemu, sisanya gak dicek lagi, dan skornya terlalu tinggi.- Lupa batas bawah. Tanpa
Math.max(0, score), aplikasi yang lebih parah bisa dapat skor minus. - Checklist cuma dibaca sekali. Konfigurasi berubah tiap deploy. Jalankan cek otomatis di CI (pelajaran berikutnya, Security Automation & Tools).
TL;DR: Security checklist adalah daftar yang dicek sebelum tiap deploy: hashing bcrypt/Argon2, cookie aman, rate limit dan 2FA, otorisasi di server, validasi input, query berparameter, output di-escape, CSRF, HTTPS dan security headers, CORS tanpa *, debug mati, secret gak di-commit, dependency diaudit, backup dan monitoring. securityAudit mulai dari 100 lalu mengurangi 25 (HTTPS), 20 (debug), 20 (CSRF), 25 (hashing selain bcrypt/argon2), dan 10 (CORS *), dengan lima if terpisah dan Math.max(0, score). Never trust user input, password minimal 8 karakter menurut NIST (15 kalau tanpa faktor kedua), dan 2FA bikin password bocor saja gak cukup.
