Cookie Login Bukan Sekadar “Ingat Saya”: Cara M…

Saat seseorang berhasil login ke website, server biasanya memberikan session cookie—sebuah tanda pengenal kecil yang disimpan di browser. Cookie inilah yang membuat pengguna tidak perlu memasukkan password di setiap halaman.

Masalahnya, siapa pun yang mendapatkan session tersebut berpotensi bertindak seolah-olah menjadi pengguna yang sah. Karena itu, keamanan login tidak berhenti pada password dan HTTPS. Atribut cookie, masa berlaku session, pergantian ID setelah login, serta cara menangani logout juga perlu diperhatikan.

Mengapa session cookie perlu diamankan?

Bayangkan session cookie seperti gelang akses di sebuah gedung. Petugas tidak selalu meminta kartu identitas di setiap ruangan; cukup dengan melihat gelang tersebut. Jika gelang itu berpindah tangan, orang lain bisa memperoleh akses yang sama.

Dalam aplikasi web, risiko ini dikenal sebagai session hijacking, yaitu pengambilalihan session milik pengguna. Kebocoran dapat terjadi melalui koneksi yang tidak aman, celah XSS, perangkat yang terinfeksi, log yang menyimpan token, atau cookie yang cakupannya terlalu luas.

OWASP merekomendasikan session ID yang panjang, acak, dan sulit ditebak. Session juga sebaiknya memiliki batas waktu, diganti setelah autentikasi, dan tidak pernah ditaruh di URL karena URL mudah masuk ke riwayat browser, log server, atau layanan analitik.

Tiga atribut cookie yang sebaiknya tidak dilupakan

1. Secure

Atribut Secure membuat browser hanya mengirim cookie melalui koneksi HTTPS. Ini penting bahkan ketika website sudah mengarahkan HTTP ke HTTPS. Tanpa atribut ini, ada skenario tertentu ketika browser masih dapat mengirim cookie melalui koneksi yang tidak terenkripsi.

2. HttpOnly

HttpOnly mencegah JavaScript di browser membaca cookie secara langsung. Atribut ini tidak menyelesaikan semua masalah XSS, tetapi dapat membatasi dampak ketika ada skrip berbahaya yang berhasil masuk ke halaman.

3. SameSite

SameSite mengatur apakah cookie boleh dikirim dalam konteks permintaan lintas situs. Nilai Lax biasanya menjadi pilihan praktis untuk banyak website, sedangkan Strict memberikan pembatasan lebih ketat tetapi dapat memengaruhi alur login dari tautan eksternal atau integrasi tertentu.

Untuk session yang sangat sensitif, konfigurasi ketat seperti Secure, HttpOnly, dan SameSite=Strict layak dipertimbangkan setelah diuji pada seluruh alur aplikasi.

Contoh konfigurasi session di PHP

PHP menyediakan session_set_cookie_params() untuk mengatur atribut cookie sebelum session dimulai. Contoh sederhananya:

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

session_start();
?>

Nilai lifetime sebesar 0 berarti cookie berlaku selama sesi browser. Untuk aplikasi dengan kebutuhan berbeda, masa berlaku dapat disesuaikan. Namun, jangan membuat session login admin aktif tanpa batas hanya demi kenyamanan.

Konfigurasi tersebut hanya efektif jika website benar-benar berjalan melalui HTTPS. Pada lingkungan pengembangan lokal yang belum memakai HTTPS, pengaturan secure=true dapat membuat cookie tidak dikirim oleh browser. Gunakan konfigurasi terpisah untuk development dan production, bukan mematikan perlindungan di server produksi.

Ganti session ID setelah login

Salah satu langkah penting adalah mengganti session ID setelah pengguna berhasil login. Tujuannya untuk mencegah session fixation, yaitu situasi ketika penyerang lebih dulu mengetahui atau memengaruhi ID session sebelum korban login.

if (password_verify($password, $user['password_hash'])) {
    session_regenerate_id(true);
    $_SESSION['user_id'] = $user['id'];
    $_SESSION['logged_in'] = true;
}

Pergantian ID juga layak dilakukan ketika pengguna menaikkan hak akses, misalnya dari pengguna biasa menjadi administrator. Setelah logout, hapus data session di server dan minta browser menghapus cookie yang berkaitan.

Bagaimana dengan WordPress?

Pada WordPress, pemilik website tidak perlu membuat sistem session sendiri untuk login standar. Fokus utama sebaiknya berada pada pembaruan WordPress core, plugin, tema, PHP, dan komponen server. Plugin atau tema dari sumber tidak tepercaya dapat membuka celah meskipun konfigurasi hosting sudah baik.

Gunakan HTTPS secara menyeluruh, batasi jumlah akun administrator, hapus plugin yang tidak dipakai, dan hindari penggunaan kredensial yang sama di banyak layanan. Jika sebuah plugin menyediakan pengaturan cookie atau login, baca dokumentasinya sebelum mengubah nilai default.

WordPress juga menekankan pentingnya backup yang benar-benar dapat dipulihkan. Backup bukan sekadar file yang tersimpan; lakukan uji restore secara berkala agar kita tahu backup tersebut masih utuh ketika insiden terjadi.

Checklist yang bisa dilakukan sekarang

Pastikan halaman login, dashboard, dan seluruh website menggunakan HTTPS.
Periksa cookie session di Developer Tools browser. Cari atribut Secure, HttpOnly, dan SameSite.
Jangan mengirim session ID melalui parameter URL.
Regenerasi session ID setelah login dan perubahan hak akses.
Tetapkan batas waktu idle dan batas usia maksimum session untuk akun sensitif.
Hapus session aktif ketika pengguna logout atau mengganti password.
Perbarui WordPress, plugin, tema, PHP, serta software server secara teratur.
Simpan backup database dan file website di lokasi berbeda, lalu uji pemulihannya.

Apa artinya bagi kita?

Keamanan session bukan fitur tambahan yang hanya diperlukan perusahaan besar. Website toko kecil, blog dengan area admin, hingga aplikasi internal sama-sama memiliki session yang dapat disalahgunakan.

Langkah seperti HttpOnly, Secure, SameSite, regenerasi ID, dan backup teruji memang tidak terlihat oleh pengunjung. Namun, justru lapisan-lapisan kecil inilah yang mengurangi peluang sebuah kesalahan sederhana berubah menjadi pengambilalihan akun atau pemulihan website yang mahal.

Untuk panduan teknis lanjutan, rujuk dokumentasi OWASP tentang atribut cookie, manual PHP session cookie, serta panduan hardening WordPress.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto