Section Security Course ini membedah serangan satu per satu dari sudut pandang penyerang, lalu membangun pertahanannya; alur itu bagus untuk belajar, tetapi tidak praktis saat rilis mendesak. Yang kita butuhkan menjelang penerbangan adalah daftar periksa: ringkas, berurutan, dan tiap barisnya menunjuk ke materi yang menjelaskannya. Chapter ini mengonsolidasikan seluruh pembahasan keamanan Course ke dalam satu tabel periksa, menegaskan kembali pola pikir aman secara bawaan yang menaunginya, lalu menutup dengan cara melaporkan kerentanan dan mengikuti kabar keamanan resmi. Perlakukan halaman ini sebagai ritual terakhir sebelum aplikasi menyentuh pengguna sungguhan.
Pola Pikir Aman secara Bawaan #
Seluruh baris daftar periksa di bawah adalah turunan dari empat kebiasaan yang dibahas tuntas pada Chapter Prinsip Keamanan Aplikasi. Pertama, jangan percaya input: setiap data dari luar — body permintaan, query parameter, header, isi berkas — diperiksa bentuk dan batasnya persis di batas sistem. Kedua, defense in depth: validasi input, parameterized query, dan escape output bekerja di lapisan berbeda yang saling menopang, sehingga satu lapisan yang bocor tidak serta-merta menjadi kebocoran data. Ketiga, least privilege: akun database, proses Node.js, hingga peran pengguna hanya menerima hak yang benar-benar diperlukan. Keempat, fail securely: ketika pemeriksaan gagal atau data tidak lengkap, aplikasi menolak — bukan meloloskan sambil berharap baik.
Daftar Periksa Sebelum Rilis #
Tabel berikut memetakan risiko ke pertahanannya. Jalankan dari atas ke bawah; setiap baris yang membuat kita berhenti dan berpikir adalah tanda untuk membuka ulang chapter rujukannya sebelum melanjutkan:
| Risiko | Pertahanan yang dipasang | Rujukan chapter |
|---|---|---|
| Input jahat lolos ke logika bisnis | Validasi bentuk dan batas di boundary: tipe, panjang, rentang, format — ditolak sebelum diproses | Validasi dan Sanitasi Input, Validasi Input |
| SQL injection | Query parameterized dengan placeholder ? atau $1; string SQL tidak pernah dirangkai dari input | Query Parameterized, SQL Injection |
| XSS lewat data pengguna | Escape output saat merender; pilih textContent di atas innerHTML; terapkan Content-Security-Policy | Cross-Site Scripting (XSS) |
| Command injection | execFile dengan array argumen; exec dihindari bila input pengguna bisa terselip ke perintah shell | Command Injection, Child Process |
| CSRF pada operasi tulis | Cookie SameSite dan token CSRF untuk permintaan yang mengubah data | Cross-Site Request Forgery (CSRF), Session dan Cookie |
| Bruteforce dan penyalahgunaan endpoint | Rate limiting per identitas dengan jendela waktu serta header Retry-After saat menolak | Rate Limiting |
| Password tersimpan terbaca | Hash dengan scrypt dan salt unik per pengguna; verifikasi memakai timingSafeEqual | Password Hashing dengan scrypt |
| Session dan token dicuri | Cookie beratribut HttpOnly, Secure, SameSite; masa berlaku token pendek dan dipatuhi | Session dan Cookie, Token dan JWT |
| Secret bocor ke repositori | Secret hidup di environment variable — dimuat lewat --env-file — dan tidak pernah ditulis di kode | Manajemen Secret, Berkas Environment dengan –env-file |
| Proses memiliki hak terlalu luas | Permission Model --permission dengan daftar izin baca-tulis yang eksplisit | Permission Model |
| Data melintas tanpa enkripsi | HTTPS di produksi, sertifikat sah, kredensial tidak pernah lewat HTTP polos | HTTPS dan TLS |
| Rute dan operasi tanpa penjaga | Middleware autentikasi konsisten di seluruh rute; otorisasi berbasis peran untuk operasi sensitif | Middleware Autentikasi, Role-Based Access Control |
Melaporkan Kerentanan #
Ketika kita menemukan celah — pada Node.js sendiri, atau pada package yang kita pakai — cara melaporkannya menentukan apakah penemuan itu menjadi perbaikan atau menjadi bencana. Proyek Node.js menjalankan halaman pelaporan keamanan resmi: kerentanan pada runtime dilaporkan secara privat lewat HackerOne, ditinjau dengan target balasan awal dalam lima hari, lalu diperbaiki dengan koordinasi embargo dan nomor CVE sebelum diumumkan bersamaan dengan rilis perbaikan. Kerentanan pada package pihak ketiga dilaporkan kepada maintainer package tersebut, bukan kepada tim Node.js.
Tetap Mutakhir #
Keamanan bukan kondisi melainkan ritme. Tim rilis Node.js mengirimkan pembaruan keamanan ke garis LTS yang masih hidup, diumumkan lewat blog resmi dan milis keamanan; karena itu aplikasi produksi sebaiknya berpegang pada garis Active LTS atau Maintenance LTS dan mengikuti pembaruan patch-nya, bukan menunda bertahun-tahun. Pastikan juga engines pada package.json menyatakan garis versi yang kita uji, sehingga lingkungan yang tidak sesuai ketahuan sejak instalasi — pembahasan lengkapnya ada di Chapter Versi Node.js dan Kompatibilitas.
Untuk pendalaman berkelanjutan, panduan praktik keamanan terbaik pada situs Learn Node.js dan rangkuman keamanan web di MDN adalah dua bacaan resmi yang selalu diperbarui. Daftar periksa ini menutup sisi manusia dan proses; sisi teknis terakhir yang perlu kita pegang sebelum menutup Course adalah memastikan fitur yang dipakai tersedia pada versi runtime target — matriksnya tersusun di Chapter Referensi Kompatibilitas.