Web Application Security Fundamentals #01: Apa Itu Web Application Security?

Web application modern hampir tidak pernah berdiri sendiri. Satu halaman login dapat melibatkan browser, CDN, reverse proxy, API, identity provider, cache, database, object storage, dan third-party service. Karena itu, Web Application Security bukan sekadar memasang HTTPS atau menjalankan vulnerability scanner menjelang deployment.

Tutorial pertama ini membangun mental model yang benar: apa yang dilindungi, dari siapa, melalui jalur apa, seberapa besar risikonya, dan control apa yang masuk akal.

Batas praktik: seluruh simulasi hanya boleh dilakukan pada aplikasi milik sendiri, local lab, atau sistem yang telah memberikan izin tertulis. Jangan menguji website publik hanya karena sebuah tool dapat dijalankan.

Tujuan pembelajaran

Setelah menyelesaikan tutorial ini, Anda dapat:

• menjelaskan scope Web Application Security;
• membedakan asset, threat, threat actor, vulnerability, exploit, likelihood, impact, dan risk;
• memetakan attack surface aplikasi sederhana;
• memahami mengapa client-side validation bukan security boundary;
• menyusun control awal menggunakan defense in depth;
• membuat baseline checklist yang dapat diuji.

Prasyarat

Siapkan browser modern dengan Developer Tools. Untuk simulasi HTTP, gunakan aplikasi milik sendiri atau local lab. Contoh command memakai curl; output dapat sedikit berbeda menurut versi tool, operating system, proxy, dan konfigurasi server.

1. Gunakan definisi yang operasional

Web Application Security adalah disiplin untuk menjaga aplikasi web beserta data yang diprosesnya dari akses, perubahan, gangguan, atau penggunaan yang tidak sah. Scope-nya bukan hanya source code, tetapi juga mencakup:

• architecture dan data flow;
• identity, authentication, authorization, dan session;
• dependency serta software supply chain;
• configuration dan deployment;
• logging, monitoring, alerting, dan incident response;
• proses development dan perubahan sistem.

OWASP Top 10 adalah awareness document tentang kategori risiko penting. Dokumen tersebut bukan checklist kelulusan, bukan sertifikasi aplikasi, dan bukan pengganti threat modeling, secure code review, OWASP ASVS, maupun security testing. Versi resmi terbaru saat tutorial ini disusun adalah OWASP Top 10:2025.

2. Bedakan istilah security

Istilah berikut sering dipakai seolah-olah sama, padahal maknanya berbeda:

• Asset: sesuatu yang bernilai, seperti account, personal data, saldo, source code, atau availability layanan.
• Threat actor: pihak yang dapat menyebabkan kerugian, baik eksternal maupun internal.
• Threat: kejadian atau kondisi yang berpotensi merugikan asset.
• Vulnerability: kelemahan yang dapat dimanfaatkan.
• Attack vector: jalur atau cara yang digunakan untuk mencapai kelemahan.
• Exploit: teknik atau kode yang memanfaatkan vulnerability.
• Impact: akibat jika sebuah skenario benar-benar terjadi.
• Likelihood: kemungkinan skenario terjadi dalam konteks tertentu.
• Risk: kombinasi likelihood dan impact dalam konteks organisasi.

Sebuah input field bukan otomatis vulnerability. Input menjadi masalah ketika untrusted data mencapai sink berbahaya tanpa validation, parameterization, output encoding, authorization, atau control relevan lainnya.

3. Petakan arsitektur sebelum mencari vulnerability

Gunakan arsitektur toko online sederhana:

Browser
   |
   v
CDN / WAF
   |
   v
Reverse Proxy
   |
   v
Web Application / API
   |             |
   v             v
Database     Object Storage
   |
   v
Payment dan Email Provider

Diagram ini bukan representasi universal. Tujuannya adalah membantu menemukan komponen dan trust boundary.

Tandai setiap lokasi saat data:

• berpindah dari user ke sistem;
• melewati network boundary;
• berubah format;
• berpindah owner atau penyedia;
• memperoleh privilege baru;
• disimpan atau dikirim ke third party.

Untuk setiap aliran data, tanyakan:

1. Siapa pengirimnya?
2. Bagaimana identity diverifikasi?
3. Apakah channel menggunakan TLS?
4. Apakah input divalidasi di server?
5. Apakah authorization diuji terhadap action dan object?
6. Data apa yang dicatat ke log?
7. Apa yang terjadi ketika dependency gagal?
8. Bagaimana credential dicabut jika bocor?

Jangan menggambar arsitektur ideal apabila production berjalan berbeda. Diagram yang rapi tetapi fiktif hanya membuat audit nyaman, bukan membuat sistem aman.

4. Amati request dan response secara aman

Periksa versi curl terlebih dahulu:

curl --version

Pada endpoint local lab atau domain yang Anda miliki, baca response header:

curl -I https://example.test

Opsi -I mengirim HEAD request. Tidak semua aplikasi memperlakukan HEAD persis seperti GET, sehingga hasilnya tidak boleh dianggap mewakili seluruh route.

Perhatikan:

• status code;
• Content-Type;
• Set-Cookie;
• Strict-Transport-Security;
• Content-Security-Policy;
• X-Content-Type-Options;
• Referrer-Policy;
• informasi server yang tidak diperlukan.

Contoh response ilustratif:

HTTP/2 200
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self'; object-src 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
set-cookie: __Host-session=REDACTED; Path=/; Secure; HttpOnly; SameSite=Lax

Contoh tersebut bukan bukti bahwa aplikasi sudah aman. Header hanya satu lapisan. Broken Access Control, injection, insecure design, business logic flaw, dan vulnerable dependency tetap mungkin ada.

5. Pahami security boundary

Semua yang berjalan di browser dapat dilihat atau dimodifikasi user. Elemen berikut membantu user experience, tetapi bukan authorization control:

• HTML attribute seperti required;
• JavaScript validation;
• hidden field;
• disabled button;
• nilai dalam Local Storage;
• route guard pada frontend.

Misalnya client mengirim payload:

{
  "productId": "550e8400-e29b-41d4-a716-446655440000",
  "quantity": 1,
  "price": 10000,
  "role": "customer"
}

Server tidak boleh mempercayai price dan role dari client. Harga harus diambil dari sumber tepercaya, sedangkan authorization harus ditentukan dari identity yang telah diverifikasi.

Pseudocode berikut menunjukkan pemisahan tanggung jawab:

const user = requireAuthenticatedUser(request);
const input = validateOrderInput(request.body);
const product = await productRepository.findById(input.productId);

authorize(user, "purchase", product);

const order = await createOrder({
  userId: user.id,
  productId: product.id,
  quantity: input.quantity,
  unitPrice: product.currentPrice
});

Validation memastikan bentuk data sesuai contract. Authentication memverifikasi siapa user. Authorization menentukan tindakan yang diperbolehkan. Ketiganya tidak dapat saling menggantikan.

6. Terapkan defense in depth

Defense in depth berarti beberapa control independen melindungi asset yang sama. Untuk account pengguna, control dapat meliputi:

• MFA untuk mengurangi dampak password compromise;
• rate limiting untuk memperlambat automated abuse;
• session rotation untuk mengurangi session fixation;
• server-side authorization;
• secure cookie attributes;
• logging dan alerting;
• recovery flow yang aman;
• least privilege untuk membatasi blast radius.

WAF tidak memahami seluruh business logic. Scanner juga tidak dapat mengetahui bahwa pengguna A dilarang membaca invoice pengguna B jika aturan bisnis tersebut tidak diberikan.

7. Tulis threat scenario

Gunakan pola berikut:

Threat actor + precondition + action + asset + impact + existing control

Contoh:

Pengguna terautentikasi mengubah invoiceId pada request.
API tidak memeriksa ownership.
Invoice pengguna lain dapat terbaca.
Confidentiality personal data terdampak.

Control yang dapat diuji:

• ownership policy pada server;
• query dibatasi menggunakan identity terautentikasi;
• automated authorization test;
• audit log untuk akses sensitif;
• alert terhadap pola object enumeration.

Skenario seperti ini jauh lebih actionable dibandingkan catatan “security perlu ditingkatkan”.

8. Buat baseline checklist

• Apakah setiap endpoint diklasifikasikan sebagai public atau authenticated?
• Apakah authorization diuji pada setiap object dan action?
• Apakah input divalidasi berdasarkan type, length, range, dan format?
• Apakah query menggunakan parameterized API?
• Apakah output di-encode sesuai context?
• Apakah secret disimpan di secret manager dan tidak masuk repository?
• Apakah dependency dipantau dan version-nya dikendalikan?
• Apakah cookie session memakai Secure, HttpOnly, dan SameSite yang sesuai?
• Apakah error response tidak membocorkan stack trace atau secret?
• Apakah security event dicatat tanpa password atau token?
• Apakah backup dan recovery telah diuji?
• Apakah vulnerability remediation memiliki owner?

Checklist harus menghasilkan evidence seperti test result, configuration, pull request, log, atau ticket. Checkbox tanpa evidence mudah berubah menjadi dekorasi compliance.

Kesalahan yang sering terjadi

Menganggap HTTPS berarti aplikasi aman

HTTPS melindungi transport antara client dan endpoint TLS. HTTPS tidak memperbaiki SQL injection, Broken Access Control, insecure file upload, maupun business logic flaw.

Menganggap internal network selalu tepercaya

Service internal tetap membutuhkan identity, authorization, validation, dan least privilege. Compromised workload dapat mengubah jalur internal menjadi attack vector.

Menjalankan scanner tanpa scope

Testing tanpa inventory dan izin dapat mengganggu sistem. Hasil scanner juga memerlukan verifikasi manual karena false positive dan false negative tetap mungkin terjadi.

Menyimpan terlalu banyak data

Data yang tidak dikumpulkan tidak dapat bocor dari sistem Anda. Data minimization merupakan keputusan desain sekaligus security control.

Checklist verifikasi tutorial

• [ ] Istilah asset, threat, vulnerability, exploit, dan risk tidak tertukar.
• [ ] Arsitektur aktual dan trust boundary telah dipetakan.
• [ ] Browser dan client dianggap untrusted.
• [ ] Authentication dan authorization dipisahkan.
• [ ] Setiap control dikaitkan dengan risk scenario.
• [ ] Tidak ada klaim “100% aman”.
• [ ] Testing hanya dilakukan pada sistem berizin.

Kesimpulan

Web Application Security dimulai dari pemahaman sistem, bukan dari daftar tool. Kenali asset, data flow, trust boundary, dan risk scenario; setelah itu pilih control serta metode pengujiannya. Pendekatan ini membuat security dapat diperiksa dan dipelihara, bukan sekadar slogan menjelang audit.

Tutorial berikutnya membahas Confidentiality, Integrity, Availability, dan Authenticity serta cara menerjemahkannya menjadi requirement yang dapat diuji.

Referensi resmi

• OWASP Top 10:2025 — diakses 22 Agustus 2026.
• OWASP: What Are Application Security Risks? — diakses 22 Agustus 2026.
• OWASP Web Security Testing Guide — diakses 22 Agustus 2026.
• OWASP Application Security Verification Standard — diakses 22 Agustus 2026.
• MDN Web Security — diakses 22 Agustus 2026.