Keamanan Aplikasi: OWASP Top 10:2025

Masuk untuk menyimpan progres Anda di semua perangkat. Sampai saat itu, progres disimpan di browser ini.

Mengapa ini penting

Keamanan adalah titik di mana kode buatan AI paling sering gagal, dan kegagalannya paling mahal. Data Veracode tahun 2026 menunjukkan tingkat lolos uji keamanan kode AI hanya sekitar 56%. Modul ini berlangsung dua minggu dan merupakan gerbang tersulit dalam program.

Capaian pembelajaran

1. Menerapkan OWASP Top 10:2025 pada aplikasi Anda sendiri.
2. Mengimplementasikan autentikasi dan otorisasi dengan benar (OAuth/OIDC, session, rotasi JWT, IAM, RLS).
3. Mengelola secret sehingga tidak ada satu pun yang sampai ke kode, bundle frontend, atau log.
4. Mencegah injection (SQL, XSS, SSRF) dan serangan browser (CSRF, salah konfigurasi CORS).
5. Mempertahankan perimeter dengan rate limiting, WAF, dan perlindungan DDoS.
6. Menjalankan SAST, DAST, pemindaian secret, dan pemindaian dependensi di CI.

OWASP Top 10:2025

Baru di 2025: Supply Chain menjadi kategori tersendiri di A03, dan Mishandling of Exceptional Conditions masuk di A10. Keduanya tepat di area di mana tool AI paling lemah.

Materi

5.1 Access control (A01, 68)

• Autentikasi = siapa Anda. Otorisasi = apa yang boleh Anda lakukan. Kode AI biasanya mengerjakan yang pertama dan lupa yang kedua.
• Cek otorisasi di setiap request, di sisi server, untuk setiap objek (WHERE id = $1 AND org_id = $currentOrg).
• Tolak secara default. Role dan permission di satu tempat (modul policy atau RLS), bukan pernyataan if yang tersebar di mana-mana.
• IAM untuk infrastruktur: setiap service punya identitas sendiri dengan least privilege; tidak ada admin key bersama; akun dev/staging/prod terpisah.
• Jangan pernah mengekspos key service-role / admin ke klien. Di Supabase, anon key memang publik sejak awal, jadi RLS adalah satu-satunya tembok Anda.

5.2 Autentikasi, OAuth, dan token (69, 70)

• Jangan membangun auth dari nol. Gunakan penyedia yang sudah terbukti (Supabase Auth, Clerk, Auth0, WorkOS untuk SSO enterprise).
• OAuth 2.0 / OIDC: Authorization Code flow dengan PKCE untuk browser dan mobile. Validasi state, nonce, issuer, audience.
• Session: cookie HttpOnly, Secure, SameSite=Lax atau Strict. Jangan simpan token di localStorage.
• Rotasi JWT: access token berumur pendek (5 sampai 15 menit), refresh token yang dirotasi dengan deteksi penggunaan ulang, signing key dirotasi lewat JWKS dengan key ID (kid), jangan pernah alg: none, selalu verifikasi tanda tangan, masa berlaku, dan audience.
• Pembeli enterprise mengharapkan: MFA, SSO (SAML/OIDC), provisioning SCIM, pencabutan session.

5.3 Manajemen secret (67)

• Secret disimpan di secrets manager atau env var platform, tidak pernah di git, tidak pernah di variabel NEXT_PUBLIC_* / VITE_* (variabel itu ikut terkirim ke browser).
• Pre-commit hook + pemindaian di CI (gitleaks, GitHub secret scanning dengan push protection).
• Secret yang bocor harus dirotasi, bukan sekadar dihapus: riwayat git dan fork menyimpannya selamanya.
• Key terpisah per environment; API key dengan cakupan minimal (restricted key Stripe, token dengan scope terbatas).
• Batas pengeluaran (spend cap) di setiap API key berbayar (LLM, SMS, peta). Tanpa itu, key yang bocor sama dengan cek kosong.

5.4 Kriptografi dan enkripsi (72, A04)

• Password: argon2id atau bcrypt lewat penyedia auth Anda. Jangan pernah melakukan hash sendiri dengan SHA.
• Enkripsi at rest: enkripsi DB/storage terkelola diaktifkan, backup terenkripsi. Enkripsi tingkat field untuk data sangat sensitif (nomor identitas nasional, detail rekening bank), dengan key di KMS.
• Gunakan library (libsodium, KMS platform); jangan pernah menciptakan kriptografi sendiri.

5.5 Injection (78, 79, 80)

• SQL injection: query berparameter atau query builder/ORM. Jangan pernah menyisipkan string ke dalam SQL, termasuk lewat jalan pintas "raw".
• XSS: framework melakukan escape secara default; zona berbahaya adalah dangerouslySetInnerHTML, v-html, serta merender markdown atau output LLM sebagai HTML. Sanitasi dengan DOMPurify; pasang Content-Security-Policy.
• SSRF: fitur apa pun yang mengambil URL dari pengguna (link preview, webhook, "impor dari URL", agen AI yang menjelajah web) bisa diarahkan ke 169.254.169.254 (metadata cloud) atau service internal. Gunakan allowlist domain, resolve dan blokir rentang IP privat, matikan redirect atau cek ulang setelah setiap redirect, jalankan fetcher di jaringan terisolasi.

5.6 Keamanan browser (76, 77)

• CORS bukan batas keamanan untuk server Anda; CORS hanya mengatur origin mana yang boleh dibaca respons-nya oleh browser. Jangan pernah memantulkan Origin sembarangan bersama Access-Control-Allow-Credentials: true. Allowlist origin yang persis.
• CSRF: cookie SameSite ditambah token CSRF atau pengecekan origin untuk request yang mengubah state saat memakai auth berbasis cookie.
• Security header: CSP, HSTS, X-Content-Type-Options: nosniff, Referrer-Policy, frame-ancestors.

5.7 Perimeter: rate limiting, WAF, DDoS (1, 74, 75)

• Rate limit berdasarkan IP, pengguna, dan API key, dengan batas lebih ketat pada login, pendaftaran, reset password, OTP, dan setiap endpoint yang memakan biaya (LLM, SMS, email).
• Algoritma: token bucket atau sliding window, disimpan di Redis atau di edge. Kembalikan 429 dengan Retry-After.
• WAF (Cloudflare, AWS WAF) dengan managed rule OWASP; perlindungan bot di halaman pendaftaran.
• Perlindungan DDoS sebagian besar datang dari CDN Anda; pastikan origin tidak bisa diakses langsung sehingga CDN bisa dilewati.

5.8 Kondisi luar biasa (A10)

• Fail closed: jika pengecekan auth melempar error, tolak. Jika pengecekan fraud timeout, tahan transaksinya, jangan disetujui.
• Jangan pernah menampilkan stack trace ke pengguna; catat di log bersama request ID.
• Tangkap error yang spesifik; jangan menelan semua exception.

5.9 Threat modelling (A06)

STRIDE dalam 30 menit per fitur: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Gambar batas kepercayaan (trust boundary); daftar kasus penyalahgunaan ("bagaimana kalau kuantitasnya -1?").

5.10 Keamanan di pipeline

Lab 5 (dua minggu): Serang aplikasi Anda sendiri

Minggu A, Bongkar: gunakan akun kedua dan proxy browser (ZAP atau Burp Community).

1. Coba baca/ubah record milik pengguna lain dengan mengganti ID (IDOR).
2. Panggil database langsung dengan anon key publik.
3. Sisipkan <script> ke setiap field teks dan output markdown/LLM.
4. Arahkan setiap fitur pengambil URL ke http://169.254.169.254/ dan http://localhost.
5. Lakukan brute force pada login dan reset password; gempur endpoint yang paling mahal.
6. Cari secret di bundle JS production.

Minggu B, Perbaiki dan buktikan: perbaiki setiap temuan, tambahkan regression test per temuan, pasang scanner ke CI.

Definition of Done

• Threat model (STRIDE) untuk dua fitur dengan risiko tertinggiBukti
• Test otorisasi: akses lintas pengguna dan lintas tenant mengembalikan 403/404 di setiap resourceBukti
• Nol secret di riwayat repo dan bundle frontend (bukti gitleaks + grep bundle)Bukti
• Spend cap terpasang di setiap API key berbayarBukti
• Rate limit pada auth, OTP, dan endpoint mahal, dibuktikan dengan testBukti
• Security header bernilai A; allowlist CORS; perlindungan CSRF di mana cookie dipakaiBukti
• Perlindungan SSRF pada setiap fitur pengambil URLBukti
• Semgrep, pemindaian dependensi, gitleaks, dan baseline ZAP berjalan di CI tanpa temuan highBukti
• Setiap temuan Minggu A punya regression testBukti

Paket prompt AI

• "Bertindaklah sebagai penetration tester. Untuk setiap route di aplikasi ini, jabarkan bagaimana pengguna yang sudah login bisa mengakses data pengguna lain. Lalu tulis test untuk masing-masing."
• "Temukan setiap tempat secret atau env var dibaca. Tandai yang bisa sampai ke bundle klien."
• "Temukan setiap tempat kita mengambil URL yang berasal dari input pengguna. Tambahkan perlindungan SSRF yang memblokir rentang privat, loopback, dan link-local setelah resolusi DNS."
• "Temukan setiap blok catch. Tandai yang fail open atau menelan error."