Web Application Security Fundamentals #03: Arsitektur Web dan Request–Response

Sebelum membahas vulnerability, kita harus memahami ke mana request bergerak. Banyak masalah security bukan muncul karena satu komponen rusak, tetapi karena dua komponen memiliki asumsi berbeda tentang identity, header, cache, encoding, atau format data.

Tutorial ini membedah aliran browser, DNS, CDN, reverse proxy, web server, API, database, cache, object storage, dan third-party service. Tujuannya bukan menghafal diagram, melainkan menemukan trust boundary dan menempatkan security control pada lokasi yang benar.

Batas praktik: gunakan hanya local lab, aplikasi milik sendiri, atau sistem yang memberikan izin tertulis. Jangan mengirim request pengujian ke target publik tanpa authorization.

Tujuan pembelajaran

Setelah menyelesaikan tutorial ini, Anda dapat:

• memetakan komponen web modern;
• mengikuti lifecycle request dan response;
• menemukan trust boundary;
• membedakan control pada browser, edge, application, dan database;
• mengenali risiko forwarding header, cache, CORS, cookie, dan third-party service;
• membuat data flow review yang dapat diverifikasi.

Prasyarat

Siapkan browser modern dengan Developer Tools dan endpoint local lab. Contoh menggunakan curl. Catat versi tool dan environment karena perilaku dapat berbeda menurut server, proxy, protocol, serta configuration.

1. Gambar arsitektur aktual

Mulai dari jalur umum berikut:

User
  |
  v
Browser
  |
  v
DNS
  |
  v
CDN / WAF
  |
  v
Reverse Proxy
  |
  v
Web Application / API
  |          |           |
  v          v           v
Database   Cache    Object Storage
                         |
                         v
                  Third-party Service

Diagram tersebut bukan arsitektur universal. Pada production, TLS dapat berakhir di CDN, load balancer, reverse proxy, atau application server. Authentication juga dapat ditangani identity provider terpisah.

Dokumentasikan kondisi nyata. Jangan menggambar arsitektur ideal apabila deployment sebenarnya berbeda.

2. Tandai trust boundary

Trust boundary muncul ketika data melewati batas dengan tingkat kepercayaan berbeda, misalnya:

• browser menuju public endpoint;
• CDN menuju origin;
• reverse proxy menuju application;
• satu microservice menuju service lain;
• application menuju database;
• sistem internal menuju third-party API;
• satu tenant menuju shared infrastructure.

Untuk setiap boundary, catat:

• identity yang digunakan;
• protocol dan encryption;
• data yang dilewatkan;
• validation;
• authentication;
• authorization;
• timeout;
• retry;
• logging;
• failure behavior.

Browser merupakan untrusted environment. Semua nilai yang datang dari browser—termasuk hidden field, cookie, header, dan JavaScript-generated data—harus diperlakukan sebagai untrusted input.

3. Ikuti lifecycle request

Sebuah request biasanya berisi:

• scheme;
• hostname;
• port;
• path;
• query;
• method;
• header;
• cookie;
• body.

Contoh request:

GET /api/orders/ord_123 HTTP/1.1
Host: app.example.test
Accept: application/json
Cookie: __Host-session=REDACTED

Alur sederhananya:

1. Browser membentuk request.
2. DNS menerjemahkan hostname.
3. Client membuat TLS connection ke endpoint HTTPS.
4. CDN atau reverse proxy menerima request.
5. Proxy memilih upstream dan meneruskan metadata tertentu.
6. Application memproses authentication, validation, authorization, dan business logic.
7. Database atau service lain memproses operasi.
8. Response kembali melewati proxy menuju browser.
9. Browser menerapkan policy seperti CORS, CSP, cookie, dan caching.

Setiap tahap dapat menambah, menghapus, atau mengubah metadata.

4. Amati request tanpa mengubah target

Pada endpoint milik sendiri:

curl --verbose   --output /dev/null   https://example.test/

Opsi --verbose dapat menampilkan informasi koneksi dan header. Sebelum membagikan output, hapus:

• cookie;
• authorization header;
• API key;
• internal hostname;
• personal data;
• correlation data yang sensitif.

Untuk membaca response header saja:

curl -sSI https://example.test/

HEAD request tidak selalu identik dengan GET. Bandingkan dengan browser Network panel dan beberapa route, termasuk error response.

5. Pahami forwarded header

Reverse proxy sering memakai header seperti:

X-Forwarded-For: 203.0.113.10
X-Forwarded-Proto: https
X-Forwarded-Host: app.example.test

Header dari client tidak otomatis tepercaya. Jika application menerima X-Forwarded-For langsung dari internet, IP-based rate limiting atau audit trail dapat menggunakan alamat palsu.

Prinsip yang lebih aman:

• tentukan daftar trusted proxy;
• hapus atau ganti forwarding header dari client;
• izinkan proxy tepercaya membentuk nilai canonical;
• konfigurasi framework sesuai jumlah dan posisi proxy;
• uji jalur direct-to-origin jika seharusnya tidak dapat diakses.

IP address juga bukan identity yang kuat. NAT, mobile network, dan shared proxy membuatnya tidak cocok sebagai satu-satunya authorization factor.

6. Bedakan origin, site, dan CORS

Origin merupakan kombinasi scheme, host, dan port. Contoh berikut berbeda origin:

https://app.example.test
https://api.example.test
http://app.example.test
https://app.example.test:8443

CORS adalah mekanisme berbasis HTTP header yang mengatur apakah browser boleh memberikan response cross-origin kepada script. CORS bukan firewall server dan bukan authorization API.

Contoh preflight:

OPTIONS /api/profile HTTP/1.1
Origin: https://app.example.test
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type

Server dapat merespons:

Access-Control-Allow-Origin: https://app.example.test
Access-Control-Allow-Methods: GET, PUT
Access-Control-Allow-Headers: content-type
Vary: Origin

Jangan merefleksikan sembarang Origin. Gunakan allowlist eksplisit apabila cross-origin access memang dibutuhkan. Authorization tetap harus dilakukan di server.

7. Periksa cache boundary

Shared cache dapat menyebabkan response personal diberikan kepada user yang salah jika cache key atau directive keliru.

Untuk data sensitif yang tidak boleh disimpan:

Cache-Control: no-store

Untuk response personal yang boleh disimpan hanya oleh private cache:

Cache-Control: private

Pilih directive berdasarkan karakter data dan kebutuhan aplikasi. Jangan menerapkan no-store secara buta pada seluruh static asset karena dapat merusak performance tanpa manfaat.

Jangan menaruh access token pada URL. URL dapat masuk:

• browser history;
• proxy log;
• analytics;
• screenshot;
• referrer;
• monitoring platform.

8. Periksa cookie boundary

Cookie memiliki aturan tersendiri untuk domain dan path. Gunakan attribute yang sesuai:

Set-Cookie: __Host-session=REDACTED; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure membatasi pengiriman melalui HTTPS.
• HttpOnly mencegah akses melalui document.cookie, tetapi tidak menyelesaikan seluruh dampak XSS.
• SameSite membatasi pengiriman pada cross-site request dalam kondisi tertentu.
• Prefix __Host- mensyaratkan Secure, Path=/, dan tanpa Domain.

Policy harus disesuaikan dengan alur login dan integration. SameSite adalah defense in depth terhadap CSRF, bukan pengganti seluruh CSRF protection.

9. Review third-party service

Setiap integration memperluas trust boundary. Untuk webhook atau API eksternal, periksa:

• authentication atau signature verification;
• TLS verification;
• replay protection;
• timeout;
• bounded retry;
• idempotency;
• data minimization;
• secret rotation;
• log redaction;
• failure behavior.

Jangan menganggap response third party selalu aman. Data dari service lain tetap harus divalidasi sesuai contract.

10. Buat data flow inventory

Gunakan tabel berikut:

Tabel harus mencerminkan production. Perbarui ketika ada endpoint, proxy, storage, atau integration baru.

Kesalahan yang sering terjadi

Menganggap CORS sebagai authorization

Request tetap dapat dikirim oleh non-browser client. Server harus melakukan authentication dan authorization terlepas dari CORS.

Mempercayai forwarding header dari client

Header dapat dipalsukan apabila proxy chain dan trusted proxy tidak dikonfigurasi dengan benar.

Menyamakan diagram deployment dan data flow

Diagram deployment menunjukkan lokasi komponen. Data flow menunjukkan data yang berpindah, identity, protocol, dan trust boundary. Keduanya saling melengkapi.

Mengabaikan error route

Security header, cache policy, dan error handling harus diperiksa juga pada response 4xx serta 5xx, bukan hanya homepage dengan status 200.

Memberikan privilege database berlebihan

Service account sebaiknya memiliki privilege minimum sesuai tugas. Least privilege membatasi blast radius jika application compromise terjadi.

Checklist verifikasi

• [ ] Diagram mencerminkan deployment aktual.
• [ ] Semua public dan internal endpoint terinventarisasi.
• [ ] Trusted proxy chain ditentukan.
• [ ] Forwarding header dari client tidak dipercaya mentah.
• [ ] CORS tidak diperlakukan sebagai authorization.
• [ ] Cache policy sesuai klasifikasi data.
• [ ] Cookie policy sesuai session design.
• [ ] Third-party integration memiliki timeout dan failure strategy.
• [ ] Secret serta token tidak masuk URL atau log.
• [ ] Error response ikut diuji.

Kesimpulan

Arsitektur memberikan peta lokasi security control. Dengan mengikuti request dari browser hingga database dan kembali lagi, kita dapat menemukan trust boundary, asumsi yang salah, serta titik tempat validation, authentication, authorization, encryption, caching, dan logging harus bekerja.

Tutorial berikutnya menggunakan peta tersebut untuk memahami OWASP Top 10:2025 secara tepat: sebagai awareness document, bukan checklist sertifikasi.

Referensi resmi

• MDN: Overview of HTTP — diakses 22 Agustus 2026.
• MDN: Same-origin policy — diakses 22 Agustus 2026.
• MDN: Cross-Origin Resource Sharing — diakses 22 Agustus 2026.
• MDN: Secure cookie configuration — diakses 22 Agustus 2026.
• OWASP REST Security Cheat Sheet — diakses 22 Agustus 2026.
• OWASP Web Security Testing Guide — diakses 22 Agustus 2026.