Satu akun admin yang bocor bisa mengubah arah seluruh website: halaman diganti, plugin berbahaya dipasang, data pengguna diunduh, bahkan akses ke server ikut terbuka. Masalahnya, banyak pemilik website masih menganggap keamanan selesai setelah memasang password kuat dan plugin keamanan.
Padahal ada lapisan lain yang sering luput: siapa boleh melakukan apa? Inilah wilayah otorisasi, yaitu proses menentukan tindakan dan data yang boleh diakses oleh pengguna yang sudah berhasil login. Seseorang bisa saja sudah terautentikasi, tetapi bukan berarti ia perlu memiliki akses ke semua menu dan fungsi.
Prinsip sederhananya adalah least privilege: berikan izin minimum yang cukup untuk menyelesaikan pekerjaan. Jika seseorang hanya menulis artikel, ia tidak perlu bisa memasang plugin. Jika sebuah aplikasi hanya perlu membaca data produk, akun database-nya tidak semestinya memiliki hak untuk menghapus seluruh tabel.
Panduan OWASP menempatkan pembatasan hak akses, penolakan akses secara default, dan pemeriksaan izin pada setiap permintaan sebagai fondasi penting keamanan aplikasi. OWASP menjelaskan prinsip ini dalam panduan Authorization.
Mengapa satu akun admin untuk semua orang berbahaya?
Menggunakan satu akun bersama memang terasa praktis. Semua orang tahu username dan password-nya, dan tidak ada waktu yang terbuang untuk mengatur akun baru. Namun, praktik ini membuat tiga hal penting menjadi kabur.
- Jejak aktivitas: ketika terjadi perubahan mencurigakan, sulit mengetahui siapa yang melakukannya.
- Pengendalian akses: semua orang memiliki izin yang sama, meskipun tanggung jawabnya berbeda.
- Pencabutan akses: ketika seseorang berhenti bekerja, password harus diganti dan semua orang perlu diberi tahu.
Lebih aman jika setiap orang memiliki akun pribadi. Dengan begitu, akses dapat dicabut tanpa mengganggu pengguna lain, dan log aktivitas bisa dikaitkan dengan identitas yang jelas.
Untuk pekerjaan sehari-hari, pisahkan juga akun biasa dan akun administratif. Akun admin digunakan hanya saat perlu mengubah konfigurasi atau memasang pembaruan. Aktivitas seperti membaca email, membuka tautan, atau mengelola konten rutin sebaiknya dilakukan dari akun dengan hak lebih rendah.
WordPress: jangan semua orang dijadikan Administrator
WordPress sudah menyediakan sistem roles dan capabilities. Role adalah kelompok pengguna seperti Editor, Author, atau Administrator, sedangkan capability adalah izin spesifik yang menentukan tindakan yang dapat dilakukan.
Editor, misalnya, dapat mengelola konten, tetapi tidak otomatis memiliki izin untuk mengubah konfigurasi inti atau memasang plugin. Administrator memiliki cakupan yang jauh lebih luas. Karena itu, memberikan role Administrator hanya karena seseorang perlu menerbitkan tulisan adalah keputusan yang terlalu longgar.
Dokumentasi resmi WordPress menyarankan agar plugin dan fitur memeriksa capability yang sesuai, bukan sekadar mengandalkan fakta bahwa pengguna sudah login. Ini penting terutama untuk pengembang plugin atau tema yang membuat halaman pengaturan dan endpoint baru.
Dalam kode WordPress, pemeriksaan seperti current_user_can() perlu dilakukan sebelum tindakan sensitif dijalankan. Menyembunyikan menu dari dashboard saja tidak cukup. Pengguna masih bisa mencoba mengakses URL secara langsung jika endpoint tersebut tidak melakukan pemeriksaan izin di sisi server.
Jangan hanya mengamankan tampilan, amankan setiap permintaan
Salah satu kesalahan umum dalam secure coding adalah mengira tombol yang disembunyikan berarti fungsi tersebut sudah aman. Padahal penyerang dapat mengirim permintaan HTTP secara manual tanpa melalui tampilan yang dibuat oleh aplikasi.
Karena itu, setiap permintaan yang mengubah data, menghapus objek, mengunggah file, atau mengubah konfigurasi harus memeriksa setidaknya:
- Apakah pengguna sudah login?
- Apakah pengguna memiliki capability yang tepat?
- Apakah objek yang diminta memang milik atau boleh diakses pengguna tersebut?
- Apakah permintaan memiliki perlindungan CSRF, seperti nonce pada WordPress?
- Apakah data yang diterima sudah divalidasi dan dibatasi?
Aturan praktisnya: jika izin tidak secara eksplisit diberikan, tolak permintaan. Pola “izinkan semua, lalu blokir beberapa kasus” lebih mudah menghasilkan celah ketika fitur baru ditambahkan.
Sesi login juga perlu diperlakukan sebagai akses sensitif
Password bukan satu-satunya tiket masuk. Setelah login, browser menyimpan identitas sesi yang memungkinkan pengguna tetap dikenali oleh server. Jika sesi ini dicuri, penyerang bisa bertindak sebagai pengguna tanpa mengetahui password.
Untuk aplikasi PHP, sesi perlu dikelola dengan hati-hati. ID sesi sebaiknya diganti setelah login berhasil atau ketika hak akses pengguna meningkat. PHP mendokumentasikan penggunaan session_regenerate_id() sebagai bagian dari perlindungan terhadap session fixation, yaitu situasi ketika penyerang mencoba memaksa korban menggunakan ID sesi yang sudah diketahui.
Gunakan juga cookie dengan atribut Secure, HttpOnly, dan SameSite sesuai kebutuhan aplikasi. Logout harus benar-benar membatalkan sesi di sisi server, bukan hanya menghapus tampilan dari browser.
Langkah yang bisa dilakukan minggu ini
- Audit semua akun. Catat siapa yang memiliki akses, kapan terakhir digunakan, dan alasan akses tersebut masih diperlukan.
- Hapus akun lama dan akun bersama. Buat akun personal agar aktivitas dapat dilacak.
- Turunkan hak akses yang terlalu tinggi. Di WordPress, gunakan Editor, Author, atau role khusus bila Administrator tidak diperlukan.
- Pisahkan akun harian dan akun admin. Jangan menggunakan akun dengan hak tertinggi untuk aktivitas biasa.
- Periksa endpoint sensitif. Pastikan setiap fungsi di server memeriksa izin, bukan hanya menyembunyikan tombol.
- Aktifkan autentikasi multifaktor. Ini membantu mengurangi dampak ketika password dicuri, meski tidak menggantikan pembatasan hak akses.
- Simpan log yang berguna. Catat login, perubahan role, pemasangan plugin, perubahan konfigurasi, dan penghapusan data.
- Uji pemulihan. Pastikan Anda tahu cara mencabut sesi, menonaktifkan akun, dan memulihkan website bila terjadi insiden.
Apa artinya bagi kita?
Pembatasan akses bukan berarti tidak mempercayai tim. Justru sebaliknya, ini cara membuat sistem tetap aman ketika manusia lupa, perangkat terinfeksi, atau satu akun jatuh ke tangan yang salah.
Keamanan yang baik tidak hanya berusaha mencegah penyerang masuk. Ia juga membatasi apa yang dapat dilakukan setelah akses diperoleh. Dengan akun personal, role yang proporsional, pemeriksaan izin di server, dan log yang jelas, satu kesalahan tidak harus berubah menjadi kerusakan seluruh website.
Dokumentasi Hardening WordPress juga menekankan pentingnya pembatasan akses, pembaruan rutin, pemisahan komponen, dan persiapan pemulihan. Tidak ada konfigurasi yang membuat website kebal selamanya, tetapi desain akses yang rapi dapat membuat insiden lebih kecil, lebih mudah dilacak, dan lebih cepat dipulihkan.
Sumber & bacaan lebih lanjut
- OWASP Authorization Cheat Sheet
- WordPress User Roles and Capabilities
- WordPress Hardening Guide
- PHP Session Management Basics
- PHP session_regenerate_id()
– Rio Yotto @rioyotto