Cookie Login Bukan Sekadar Centang HTTPS: Cara Mengamankan Session di PHP dan WordPress

HTTPS penting, tetapi ia bukan satu-satunya penjaga akun pengguna. Setelah seseorang login, website biasanya menyimpan tanda pengenal di browser berupa cookie session. Cookie inilah yang membuat pengguna tidak perlu memasukkan password di setiap halaman.

Masalahnya, siapa pun yang mendapatkan session cookie yang masih berlaku bisa saja ikut dianggap sebagai pengguna tersebut. Karena itu, keamanan session perlu diperlakukan seperti keamanan kunci rumah: bukan hanya bagaimana kunci dikirim, tetapi juga bagaimana kunci dibuat, disimpan, diganti, dan dicabut.

Session cookie itu apa?

Session cookie adalah data kecil yang dikirim server ke browser setelah pengguna membuka atau masuk ke sebuah aplikasi. Isinya biasanya bukan password, melainkan ID acak yang merujuk ke data session di server.

Contohnya, server dapat menyimpan informasi bahwa ID abc123 adalah milik pengguna tertentu. Browser lalu mengirimkan ID tersebut pada request berikutnya. Jika ID ini bocor, penyerang tidak harus mengetahui password untuk mencoba mengambil alih session.

Itulah sebabnya session ID tidak boleh dimasukkan ke URL, disimpan sembarangan di halaman, atau dicetak ke log aplikasi. URL bisa masuk ke riwayat browser, analytics, log server, bahkan header referer.

Tiga atribut cookie yang wajib diperiksa

Secure: hanya lewat HTTPS

Atribut Secure membuat browser hanya mengirim cookie melalui koneksi HTTPS. Ini mengurangi risiko session ID terlihat ketika pengguna berada di jaringan yang tidak terpercaya.

Namun, Secure bukan pengganti HTTPS. Website tetap harus memaksa seluruh halaman menggunakan HTTPS dan sebaiknya tidak mencampur halaman aman dengan resource yang masih dikirim melalui HTTP.

HttpOnly: jangan biarkan JavaScript membaca cookie

HttpOnly mencegah cookie dibaca melalui API JavaScript seperti document.cookie. Ini membantu membatasi pencurian cookie ketika terjadi XSS atau Cross-Site Scripting, yaitu kondisi ketika kode berbahaya berhasil masuk dan dijalankan di halaman website.

Atribut ini tidak membuat XSS menjadi tidak berbahaya. Script jahat masih mungkin mengirim request atas nama pengguna dari browser yang sedang aktif. Karena itu, pencegahan XSS dan perlindungan CSRF tetap diperlukan.

SameSite: batasi pengiriman lintas situs

SameSite mengatur apakah cookie boleh ikut dikirim ketika request berasal dari situs lain. Untuk banyak website, Lax adalah pilihan yang cukup praktis. Strict memberikan pembatasan lebih ketat, tetapi dapat mengganggu alur login atau navigasi tertentu.

Jangan menjadikan SameSite sebagai satu-satunya perlindungan CSRF. Untuk aksi penting seperti mengganti email, password, atau menghapus data, tetap gunakan CSRF token dan validasi di sisi server.

Regenerasi session setelah login

Salah satu kesalahan yang sering luput adalah memakai ID session yang sama sebelum dan sesudah login. Pola ini membuka peluang session fixation: penyerang mencoba membuat korban menggunakan ID session tertentu, lalu berharap ID itu tetap aktif setelah korban berhasil login.

Solusinya sederhana: ganti ID session ketika terjadi perubahan hak akses, terutama setelah login. Dalam PHP, pola dasarnya dapat terlihat seperti ini:

<?php
session_start();

if ($login_berhasil) {
    session_regenerate_id(true);
    $_SESSION['user_id'] = $user_id;
    $_SESSION['login_at'] = time();
}
?>

Regenerasi juga layak dipertimbangkan setelah perubahan password, pemulihan akun, atau peningkatan hak akses. Jangan hanya mengandalkan alamat IP atau user-agent untuk mengikat session; keduanya dapat berubah dan tidak selalu menjadi indikator identitas yang kuat.

Contoh konfigurasi session di PHP

Konfigurasi cookie harus ditetapkan sebelum session_start(). Pada PHP modern, pengaturan dapat ditulis seperti berikut:

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

session_start();
?>

lifetime bernilai nol agar cookie menjadi session cookie yang biasanya berakhir ketika browser ditutup. Untuk aplikasi yang memang membutuhkan fitur “ingat saya”, gunakan durasi terbatas, token terpisah, dan mekanisme pencabutan token. Jangan membuat sesi login permanen tanpa alasan yang jelas.

Jika website berada di balik reverse proxy atau CDN, pastikan aplikasi dapat mengenali bahwa request asli menggunakan HTTPS. Konfigurasi yang keliru bisa membuat cookie tidak diberi atribut Secure, atau membuat redirect HTTPS bekerja tidak konsisten.

Bagaimana dengan WordPress?

WordPress menangani autentikasi melalui beberapa cookie dan token internal. Pengelola website tidak seharusnya mengganti mekanisme login dengan kode buatan sendiri tanpa memahami alur cookie, nonce, dan validasi kemampuan pengguna.

Langkah praktisnya adalah memastikan alamat WordPress dan Site Address menggunakan HTTPS, memperbarui core serta plugin, menghapus plugin yang tidak dipakai, dan tidak memasang kode yang menonaktifkan pemeriksaan keamanan bawaan. Untuk fitur login khusus, gunakan API WordPress dan validasi server-side, bukan hanya menyembunyikan tombol di halaman.

Fitur “ingat saya” juga perlu dipahami. Cookie yang persisten memang nyaman, tetapi memperpanjang masa ketika akun dapat diakses dari perangkat yang hilang atau dipinjam orang lain. Untuk akun administrator, pertimbangkan masa login yang lebih pendek dan autentikasi tambahan.

Logout bukan sekadar mengarahkan ke halaman login

Logout yang benar harus membatalkan session di server, menghapus cookie yang terkait, dan memastikan token lama tidak dapat dipakai kembali. Mengarahkan pengguna ke halaman login tanpa mencabut session bukan logout yang sesungguhnya.

Untuk aplikasi yang menyimpan data sensitif, gunakan header seperti Cache-Control: no-store pada response tertentu agar halaman privat tidak tersimpan di cache browser atau perantara. Setelah logout, pengguna juga sebaiknya tidak bisa kembali melihat halaman akun hanya dengan menekan tombol Back lalu memuat salinan cache lama.

Yang bisa dilakukan sekarang

1. Periksa cookie login melalui Developer Tools browser. Pastikan terdapat Secure, HttpOnly, dan SameSite.
2. Pastikan session ID tidak muncul di URL, HTML, pesan error, atau log yang dapat diakses terlalu banyak orang.
3. Regenerasi session setelah login dan perubahan hak akses.
4. Batasi masa berlaku session, terutama untuk panel admin.
5. Pastikan logout mencabut session di server, bukan hanya menghapus tampilan cookie.
6. Uji ulang alur login setelah mengaktifkan HTTPS, CDN, reverse proxy, atau plugin keamanan.

Keamanan session bukan satu fitur yang selesai dipasang sekali. Ia adalah rangkaian keputusan kecil yang saling melengkapi: transport terenkripsi, cookie dengan atribut yang tepat, ID yang berganti saat status berubah, timeout yang masuk akal, dan logout yang benar-benar mencabut akses.

Sumber & bacaan lebih lanjut

• OWASP Session Management Cheat Sheet
• PHP Manual: session_set_cookie_params
• PHP Manual: Securing Session INI Settings
• WordPress Developer Resources: wp_set_auth_cookie()

– Rio Yotto @rioyotto