Hari ini saya mulai masuk ke wilayah yang paling saya tunggu sekaligus paling saya takuti sebagai programmer: keamanan aplikasi web. Selama ini saya tahunya “aplikasi web itu ya HTTP, endpoint, database” — tapi ternyata setiap endpoint itu adalah pintu, dan setiap pintu bisa didorong dari luar. Di episode #1 kita sudah bicara CIA Triad sebagai cara berpikir; kali ini saya catat peta praktisnya: OWASP Top 10 dan konsep attack surface.
Attack surface: semua yang bisa disentuh penyerang
Analogi sederhana yang saya pakai: attack surface adalah jumlah “lubang” pada gedung yang bisa dicoba orang asing — bukan cuma pintu depan, tapi jendela, ventilasi, saluran air, sampai kotak pos. Dalam aplikasi web, attack surface mencakup:
- Semua endpoint HTTP (termasuk yang jarang dipakai dan sering terlupa, misalnya route debug atau backup lama)
- Setiap kolom input: form login, search, upload file, bahkan parameter URL seperti
?id=123 - API yang dilayani (sering tidak se-terproteksi halaman web utama)
- Header HTTP, cookie, dan token yang dikirim browser
- Konfigurasi server, CORS, directory listing, file .git yang ikut ter-deploy
Prinsip yang saya catat: makin banyak permukaan, makin besar peluang salah konfigurasi. Itulah kenapa di episode #6 kita bicara membatasi port yang terbuka — pola pikirnya sama, hanya skala aplikasi.
OWASP Top 10: peta risiko versi 2025
OWASP (Open Worldwide Application Security Project) menerbitkan daftar 10 risiko keamanan web paling kritis, diperbarui terakhir final November 2025. Versi 2025 ini menarik buat saya karena dua kategori baru muncul dan satu peringkat naik drastis. Ini daftar lengkapnya:
| Kode | Risiko | Inti masalah |
|---|---|---|
| A01:2025 | Broken Access Control | Pengguna bisa mengakses data/fitur yang bukan miliknya |
| A02:2025 | Security Misconfiguration | Default config dibiarkan, fitur debug aktif, CORS longgar |
| A03:2025 | Software Supply Chain Failures | Ketergantungan pihak ketiga/dependency yang dikompromikan (BARU) |
| A04:2025 | Cryptographic Failures | Data sensitif dienkripsi lemah atau tidak sama sekali |
| A05:2025 | Injection | Input pengguna dieksekusi sebagai kode/query (SQLi, XSS, dll) |
| A06:2025 | Insecure Design | Risiko lahir dari desain, bukan sekadar implementasi salah |
| A07:2025 | Authentication Failures | Login lemah, sesi mudah dicuri, brute force dibiarkan |
| A08:2025 | Software or Data Integrity Failures | Update/CI-CD/kurasi data tanpa verifikasi integritas |
| A09:2025 | Security Logging and Alerting Failures | Kejadian tak tercatat, tidak ada peringatan |
| A10:2025 | Mishandling of Exceptional Conditions | Error/exception diabaikan sampai jadi celah (BARU) |
Apa yang berubah dari versi 2021
Yang membuat saya berkaca-kaca: dua kategori baru keduanya “modern developer problems”. A03 Software Supply Chain Failures lahir karena kasus seperti xz utils dan rentetan kompromis dependency npm/PyPI — bukan salah kita menulis kode, tapi salah kita percaya paket pihak ketiga tanpa verifikasi. Dan A10 Mishandling of Exceptional Conditions — hmm, ini pribadi banget: selama ini saya menganggap try/catch hanya urusan “biar tidak crash”, ternyata menelan error diam-diam juga bisa membuka jalan penyerang.
Dua perubahan lain yang saya catat: Security Misconfiguration naik dari #5 ke #2 — data menunjukkan miskonfigurasi lebih sering jadi pintu masuk daripada kode yang bocor — dan SSRF (Server-Side Request Forgery) kini digabung ke dalam Broken Access Control. Peringkat Injection turun ke #5, tapi tetap kategori dengan jumlah CVE terbanyak, jadi bukan berarti aman.
Cara saya memakai daftar ini (bukan sebagai checklist doang)
Kesalahan pemahaman saya awalnya: menganggap OWASP Top 10 sebagai kotak centang — centang semua, selesai. Padahal OWASP sendiri menegaskan daftar ini adalah peringkat risiko, bukan checklist kepatuhan. Yang saya terapkan sekarang:
- Desain dulu, kode kemudian (A06): sebelum menulis fitur, tanyakan “bagaimana fitur ini bisa disalahgunakan?” — mirip TDD, tapi untuk ancaman.
- Default tolak (A01): setiap endpoint baru, akses ditolak kecuali dideklarasikan izinnya.
- Audit dependency berkala (A03/A08):
npm audit/composer auditbukan tugas “nanti kalau sempat”. - Log yang bisa dibaca orang (A09): mencatat kejadian tidak cukup kalau tidak ada yang membaca dan mengingatkan.
Untuk tiga kategori yang paling “coder-facing” — Injection (A05), Authentication Failures (A07), dan Broken Access Control (A01) — saya akan bahas tuntas satu per satu di episode berikutnya, dimulai dari SQL Injection. Persiapan yang saya sudah lakukan: menyiapkan lab lokal sengaja vulnerabel supaya bisa latihan secara legal di mesin sendiri. Mengingatkan diri sendiri: menguji keamanan tanpa izin tertulis adalah pelanggaran UU ITE — semua latihan harus di lingkungan milik sendiri atau program resmi.
Sumber
- OWASP Top 10:2025 (situs resmi) — https://top10.owasp.org/2025/
- OWASP Foundation, halaman proyek Top Ten — https://owasp.org/projects/top-ten
- Repositori dokumen resmi OWASP Top 10 — https://github.com/OWASP/Top10
- Qualys, “What Changed in OWASP Top 10 2025” (15 Juni 2026) — tautan
Komentar Terbaru