flawopen.com/Referensi/JWT vs cookie HttpOnly
JWT di localStorage vs cookie HttpOnly: mana yang lebih aman?
Untuk banyak aplikasi web, sesi yang dikelola server dan dikirim melalui cookie HttpOnly adalah pilihan awal yang kuat. JavaScript tidak dapat membaca cookie tersebut sehingga pengambilan token lebih sulit, tetapi XSS tidak menjadi netral: skrip dari origin yang sama masih dapat mengirim permintaan terautentikasi dan membaca data yang tersedia bagi halaman.
Trade-off keamanan
| Penyimpanan / pengiriman | Paparan XSS | Perilaku CSRF | Pencabutan |
|---|---|---|---|
localStorage bearer token | JavaScript dari origin yang sama dapat membacanya; XSS dapat mencuri atau bertindak sebagai pengguna. | Tidak otomatis dilampirkan ke permintaan lintas situs; XSS dan CSRF sisi klien tetap berisiko. | JWT mandiri dapat tetap berlaku sampai kedaluwarsa jika pencabutan tidak diperiksa. |
HttpOnly cookie | JavaScript tidak dapat membaca nilainya; XSS tetap dapat mengirim permintaan terautentikasi. | Dikirim otomatis sesuai aturan cookie; SameSite hanya salah satu lapisan CSRF. | Sesi opak dapat dibatalkan di server; JWT dalam cookie perlu kebijakan pencabutan tersendiri. |
Arsitektur yang direkomendasikan
- ✓Simpan pengenal sesi dalam cookie
HttpOnly; Secure; SameSite=Lax. - ✓Hindari menyimpan token autentikasi persisten di
localStorageatausessionStorage.
Bedakan format token, penyimpanan, dan status sesi
JWT adalah format token; localStorage dan cookie adalah mekanisme penyimpanan dan pengiriman di browser. JWT dapat disimpan di salah satunya. Pengenal sesi opak dalam cookie biasanya menunjuk ke status sesi yang dikelola server. “JWT atau cookie” bukan perbandingan langsung antara opsi yang setara.
Dampak tiap pilihan
Browser tidak otomatis menyertakan nilai localStorage dalam permintaan lintas situs, tetapi XSS dari origin yang sama tetap dapat membaca bearer token atau bertindak melalui aplikasi. Cookie dikirim otomatis sesuai aturan browser; HttpOnly menyembunyikan nilainya dari JavaScript, tetapi tidak mencegah skrip sisipan memakai halaman yang sudah masuk. SameSite=Lax adalah satu lapisan CSRF, bukan jaminan menyeluruh: navigasi tingkat atas dengan metode aman dan permintaan same-site tetap perlu diperhitungkan. Jangan mengubah status melalui GET; gunakan pertahanan CSRF yang sesuai, seperti token tervalidasi dan/atau pemeriksaan Origin.
Pencabutan bergantung pada status server dan validasi token, bukan lokasi penyimpanan. Sesi server dapat dibatalkan dengan menghapus catatannya. JWT mandiri dapat tetap diterima sampai kedaluwarsa kecuali validator memeriksa pencabutan; masa berlaku pendek memperkecil jendela itu, tetapi tidak menghapusnya.
Titik awal praktis
- ✓Untuk aplikasi web sendiri, utamakan sesi server yang opak atau Backend-for-Frontend (BFF) jika sesuai arsitektur.
- ✓Atur cookie sesi dengan
Secure,HttpOnly, nilaiSameSiteyang dipilih sengaja,Path=/, dan tanpaDomainbila memungkinkan; pertimbangkan__Host-. - ✓Gunakan token CSRF dan/atau validasi Origin untuk permintaan yang mengubah status sesuai model ancaman; jangan mengubah status melalui
GET. - ✓Jika JWT di browser diperlukan, gunakan masa berlaku singkat, tetapkan logout/pencabutan, dan cegah XSS. Cookie bukan pengganti pemeriksaan otorisasi.