Cookie Login yang Aman: Memahami Secure, HttpOnly, dan SameSite

Ketika seseorang berhasil login, website biasanya tidak meminta password pada setiap halaman. Browser menyimpan sebuah session cookie—penanda yang memberi tahu server bahwa pengguna sudah terautentikasi. Jika cookie ini bocor atau dikirim dalam konteks yang salah, penyerang bisa memanfaatkannya untuk bertindak sebagai pengguna tersebut.

Karena itu, keamanan login tidak berhenti pada password yang kuat. Atribut cookie seperti Secure, HttpOnly, dan SameSite adalah lapisan pertahanan penting. Namun, ketiganya memiliki fungsi berbeda dan tidak boleh dianggap sebagai tombol ajaib yang menyelesaikan semua masalah. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html?utm_source=openai))

Tiga atribut yang perlu dipahami

1. Secure: hanya kirim melalui HTTPS

Atribut Secure membuat browser hanya mengirim cookie melalui koneksi HTTPS. Ini membantu mencegah session ID terbaca ketika lalu lintas jaringan disadap, misalnya saat pengguna memakai Wi-Fi publik.

Perlu dicatat, memasang HTTPS saja belum cukup jika cookie tidak memiliki atribut Secure. Tanpa atribut tersebut, browser dapat saja mengirim cookie melalui koneksi HTTP pada kondisi tertentu. Karena itu, website yang memang hanya berjalan melalui HTTPS sebaiknya menetapkan Secure secara konsisten. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html?utm_source=openai))

2. HttpOnly: batasi akses dari JavaScript

HttpOnly mencegah cookie dibaca melalui document.cookie. Ini mengurangi dampak dari sebagian skenario XSS, yaitu ketika skrip berbahaya berhasil dijalankan di halaman website.

Atribut ini bukan berarti XSS menjadi tidak berbahaya. Browser tetap akan mengirim cookie secara otomatis ketika skrip melakukan request ke website yang sama. Artinya, HttpOnly membantu melindungi kerahasiaan cookie, tetapi tidak menggantikan pencegahan XSS, validasi input, atau Content Security Policy. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html?utm_source=openai))

3. SameSite: kendalikan request lintas situs

SameSite memberi tahu browser kapan cookie boleh dikirim pada request yang berasal dari situs lain. Nilai Strict paling ketat, sedangkan Lax biasanya menawarkan kompromi yang lebih nyaman untuk website umum. Nilai None mengizinkan pengiriman lintas situs dan wajib disertai Secure.

SameSite berguna sebagai pertahanan tambahan terhadap CSRF, tetapi bukan pengganti token CSRF. Misalnya, mode Lax masih mengizinkan beberapa navigasi tingkat atas dengan metode aman seperti GET. Karena itu, endpoint yang mengubah data tidak boleh menggunakan GET, dan operasi penting tetap perlu dilindungi token CSRF atau mekanisme verifikasi lain. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html?utm_source=openai))

Contoh konfigurasi PHP

Untuk aplikasi PHP sederhana, pengaturan cookie sesi sebaiknya dilakukan sebelum session_start(). Contoh berikut cocok sebagai titik awal untuk website yang seluruhnya menggunakan HTTPS:

<?php
session_set_cookie_params([
    'lifetime' => 0,
    'path' => '/',
    'domain' => '',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'
]);

session_start();

lifetime bernilai nol berarti cookie sesi biasanya berakhir ketika browser ditutup. Ini belum tentu cocok untuk fitur “ingat saya”, tetapi lebih aman daripada membuat sesi login bertahan tanpa batas. Untuk aplikasi dengan risiko tinggi, waktu idle dan masa berlaku sesi juga perlu dibatasi di sisi server.

PHP mendukung pengaturan secure, httponly, dan samesite melalui session_set_cookie_params(). Jika opsi tidak ditetapkan, atribut tertentu bisa tidak dikirim sama sekali, sehingga perilaku browser bergantung pada konfigurasi dan default yang berlaku. ([php.net](https://www.php.net/session-set-cookie-params?utm_source=openai))

Jangan memperluas cookie tanpa alasan

Salah satu konfigurasi yang sering luput diperiksa adalah Domain. Jika cookie dibuat untuk example.com, cookie itu dapat dikirim ke subdomain seperti blog.example.com dan admin.example.com. Ini mungkin diperlukan dalam arsitektur tertentu, tetapi juga memperbesar area risiko: kelemahan pada satu subdomain berpotensi memengaruhi cookie yang dipakai aplikasi lain.

Jika sesi hanya digunakan oleh satu host, biasanya lebih aman tidak menetapkan atribut Domain. Untuk cookie yang hanya berlaku pada host tertentu dan seluruh path, prefix __Host- dapat dipertimbangkan. Prefix ini mensyaratkan HTTPS, tidak menggunakan Domain, dan memakai Path=/. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html?utm_source=openai))

Contoh header yang lebih ketat:

Set-Cookie: __Host-SessionID=nilai-acak; Path=/; Secure; HttpOnly; SameSite=Lax

Hal yang sering salah dalam implementasi

• Menyimpan token login di localStorage. Data di Web Storage dapat dibaca oleh JavaScript pada origin yang sama. Jika terjadi XSS, token berpotensi ikut terekspos. Untuk sesi browser, cookie HttpOnly lebih tepat dalam banyak skenario. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html?utm_source=openai))
• Menggunakan GET untuk mengubah data. URL seperti /hapus-akun?id=123 dapat dipanggil dari berbagai konteks dan berisiko dipicu tanpa sengaja. Gunakan POST, PUT, PATCH, atau DELETE sesuai kebutuhan, lalu tambahkan perlindungan CSRF.
• Menganggap logout hanya menghapus cookie. Sesi juga perlu dinonaktifkan di server. Jika session ID lama masih valid, cookie yang pernah tercuri mungkin tetap dapat digunakan.
• Membiarkan sesi lama setelah login atau perubahan hak akses. Buat ulang session ID setelah autentikasi dan ketika terjadi perubahan privilese. Dengan begitu, ID yang mungkin sudah diketahui sebelum login tidak terus dipakai.
• Mengaktifkan SameSite=Strict tanpa menguji alur bisnis. Pengaturan paling ketat dapat mengganggu alur login dari email, pembayaran, atau integrasi pihak ketiga. Pilih konfigurasi berdasarkan kebutuhan, bukan sekadar mengejar nilai paling ketat.

Yang bisa dilakukan sekarang

1. Buka Developer Tools browser, periksa tab Application atau Storage, lalu lihat cookie sesi.
2. Pastikan cookie autentikasi memiliki Secure dan HttpOnly.
3. Pastikan SameSite ditetapkan secara eksplisit sebagai Lax atau Strict, bukan dibiarkan tanpa keputusan.
4. Periksa apakah atribut Domain benar-benar diperlukan. Jika tidak, hapus atribut tersebut.
5. Uji login, logout, pergantian password, perubahan email, dan kenaikan hak akses. Pastikan session ID dibuat ulang pada momen penting.
6. Audit endpoint yang mengubah data. Tidak boleh ada aksi destruktif yang hanya bergantung pada request GET.

Intinya

Cookie login adalah kunci sementara menuju akun pengguna. Secure melindunginya saat dikirim melalui jaringan, HttpOnly membatasi pembacaan dari JavaScript, dan SameSite membantu mengurangi request lintas situs yang tidak diinginkan. Ketiganya akan bekerja lebih baik jika dipadukan dengan HTTPS, pencegahan XSS, token CSRF, rotasi session ID, serta logout yang benar-benar mengakhiri sesi di server.

Jika Anda mengelola website WordPress atau aplikasi PHP lama, pemeriksaan cookie adalah langkah kecil dengan manfaat besar. Tidak perlu menunggu insiden untuk mengetahui bahwa cookie sesi ternyata dikirim tanpa perlindungan dasar.

Sumber & bacaan lebih lanjut

• OWASP Session Management Cheat Sheet
• MDN: Set-Cookie header
• MDN: Secure cookie configuration
• PHP Manual: session_set_cookie_params
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet

– Rio Yotto @rioyotto