Website perusahaan bukan sekadar media informasi. Di baliknya sering terdapat data pelanggan, akun admin, formulir bisnis, integrasi layanan, hingga database yang penting untuk operasional.
Karena itu, keamanan website perlu dibangun secara berlapis. Tujuannya bukan hanya mencegah deface atau malware, tetapi juga menjaga data, reputasi bisnis, dan kontinuitas layanan agar tetap berjalan.
Kenapa Website Perusahaan Menjadi Target Serangan?
Banyak pemilik bisnis mengira serangan hanya menyasar perusahaan besar. Faktanya, banyak serangan website dilakukan secara otomatis menggunakan bot yang memindai ribuan domain untuk mencari celah keamanan.
Bot dapat mencoba login berulang, mencari plugin rentan, memindai endpoint terbuka, hingga mencoba mengeksekusi file tertentu.
Beberapa faktor yang sering meningkatkan risiko antara lain:
- password admin lemah;
- plugin atau CMS tidak diperbarui;
- endpoint terbuka tanpa pembatasan;
- permission file terlalu longgar;
- halaman login tidak dilindungi;
- tidak menggunakan firewall;
- terlalu banyak akun administrator.
Karena serangan bisa terjadi secara otomatis, keamanan website perlu diposisikan sebagai bagian dari sistem, bukan hanya tindakan setelah website diretas.
Terapkan Web Application Firewall sebagai Lapisan Pertama
Web Application Firewall atau WAF berfungsi menyaring request sebelum mencapai aplikasi atau server.
Secara sederhana, WAF dapat dianggap sebagai penjaga di depan website. Setiap request diperiksa terlebih dahulu sebelum diteruskan.
Request yang terlihat mencurigakan dapat diblokir, ditantang dengan challenge, atau dibatasi berdasarkan aturan tertentu.
1. Gunakan Cloudflare Security Rules
Cloudflare dapat menjadi salah satu lapisan proteksi di depan server website.
Melalui security rules, administrator dapat membuat aturan berdasarkan pola request, lokasi, IP, metode HTTP, URI, dan parameter lainnya.
Contoh penerapannya antara lain:
- memblokir request ke endpoint sensitif;
- membatasi akses ke halaman login;
- mendeteksi pola traversal;
- memblokir bot tertentu;
- memberikan challenge pada trafik mencurigakan;
- memfilter request dengan pola exploit.
Keuntungan pendekatan ini adalah request berbahaya dapat dihentikan sebelum mencapai server utama.
Dengan begitu, bukan hanya keamanan yang meningkat, tetapi beban server juga dapat berkurang.
2. Batasi Brute Force pada Halaman Login
Brute force adalah percobaan login berulang menggunakan banyak kombinasi username dan password.
Pada WordPress, halaman seperti /wp-login.php sering menjadi sasaran karena lokasinya mudah diketahui.
Untuk mengurangi risiko, beberapa proteksi yang dapat digunakan antara lain:
- rate limiting;
- CAPTCHA atau challenge;
- pembatasan request per IP;
- firewall rule;
- login attempt limit;
- allowlist IP untuk admin tertentu.
Jika halaman login perusahaan hanya digunakan oleh tim internal, pembatasan berdasarkan IP atau VPN bahkan bisa menjadi pilihan yang lebih ketat.
Hardening File Sistem agar Tidak Mudah Dimodifikasi
Firewall saja belum cukup.
Jika penyerang berhasil menemukan celah melalui plugin, theme, atau konfigurasi aplikasi, file sistem menjadi lapisan berikutnya yang harus terlindungi.
Hardening file sistem bertujuan memperkecil kemampuan proses tidak sah untuk membaca, menulis, atau memodifikasi file penting.
1. Lindungi wp-config.php
Pada WordPress, wp-config.php termasuk file paling penting karena berisi konfigurasi database, security keys, dan beberapa pengaturan sistem lainnya.
File ini sebaiknya tidak dapat diakses secara langsung melalui browser.
Selain itu, hindari menyimpan file cadangan seperti:
- wp-config.bak;
- wp-config-old.php;
- wp-config.txt;
- salinan konfigurasi lain di folder publik.
File backup seperti ini berbahaya jika web server salah menginterpretasikan ekstensi dan malah menampilkan isinya.
2. Gunakan Permission File 644 dan Folder 755
Permission menentukan siapa yang dapat membaca, menulis, atau menjalankan file.
Konfigurasi yang umum digunakan pada banyak instalasi website adalah:
- file: 644;
- folder: 755.
Dengan konfigurasi ini, file masih dapat dibaca oleh sistem tetapi tidak bebas dimodifikasi oleh semua user.
Permission terlalu longgar seperti 777 sebaiknya dihindari karena memberikan hak akses yang terlalu besar.
Namun konfigurasi permission tetap harus disesuaikan dengan web server, user ownership, dan arsitektur hosting yang digunakan.
3. Nonaktifkan File Editing dari Dashboard
WordPress secara default memungkinkan administrator mengedit file theme atau plugin langsung dari dashboard.
Fitur ini praktis, tetapi menjadi risiko tambahan apabila akun administrator berhasil diambil alih.
Untuk menonaktifkannya, dapat ditambahkan konfigurasi:
define(‘DISALLOW_FILE_EDIT’, true);
Dengan cara ini, admin yang berhasil login tidak langsung memiliki fasilitas untuk menyisipkan kode melalui editor bawaan WordPress.
Perubahan file sebaiknya dilakukan melalui mekanisme yang lebih terkontrol seperti deployment, SFTP, SSH, atau file manager dengan akses terbatas.
Amankan Endpoint yang Sering Dimanfaatkan Penyerang
Website modern memiliki banyak endpoint yang digunakan untuk komunikasi antar sistem.
Masalahnya, endpoint yang tidak dikontrol dapat dimanfaatkan untuk enumeration, brute force, spam, atau serangan otomatis lainnya.
Karena itu, endpoint sebaiknya hanya dibuka sesuai kebutuhan.
A. Batasi REST API Sesuai Kebutuhan
REST API pada WordPress memiliki banyak fungsi penting.
API ini digunakan oleh editor, aplikasi pihak ketiga, integrasi, dan fitur modern WordPress.
Karena itu, pendekatan yang lebih aman bukan selalu mematikannya seluruhnya.
Administrator dapat membatasi endpoint tertentu yang tidak diperlukan publik, misalnya endpoint yang menampilkan informasi user.
Prinsip yang digunakan adalah least privilege, yaitu hanya memberikan akses sesuai kebutuhan.
Jika endpoint tertentu hanya diperlukan untuk user login, batasi akses untuk user yang sudah terautentikasi.
B. Nonaktifkan XML-RPC Jika Tidak Digunakan
XML-RPC merupakan fitur lama WordPress yang memungkinkan komunikasi jarak jauh dengan website.
Fitur ini masih dibutuhkan oleh beberapa layanan, tetapi sering pula menjadi sasaran abuse.
Pada website yang tidak menggunakan XML-RPC, endpoint ini dapat dinonaktifkan atau dibatasi melalui web server, plugin security, atau Cloudflare rule.
Sebelum menonaktifkannya, periksa terlebih dahulu apakah ada integrasi yang masih bergantung pada fitur tersebut.
Jangan Hanya Mengandalkan Password Admin
Password panjang dan unik tetap penting, tetapi password saja belum cukup untuk akun dengan hak akses tinggi.
Credential bisa bocor melalui phishing, malware perangkat, password reuse, atau kebocoran data layanan lain.
Karena itu, autentikasi admin sebaiknya menggunakan lapisan tambahan.
A. Terapkan Two-Factor Authentication
Two-Factor Authentication atau 2FA meminta verifikasi kedua setelah password dimasukkan.
Verifikasi dapat berasal dari:
- aplikasi authenticator;
- security key;
- passkey;
- metode autentikasi tambahan lainnya.
Jika password admin bocor, penyerang tetap membutuhkan faktor kedua untuk masuk.
2FA sangat disarankan minimal untuk:
- administrator;
- developer;
- user yang memiliki akses server;
- user dengan akses mengubah plugin atau theme;
- akun dengan hak mengelola user.
B. Batasi Jumlah Akun Administrator
Semakin banyak akun admin, semakin banyak pula titik yang harus diamankan.
Perusahaan sebaiknya melakukan audit user secara berkala.
Akun mantan staf, developer lama, vendor yang sudah tidak aktif, atau user sementara sebaiknya dihapus atau diturunkan hak aksesnya.
Gunakan role sesuai kebutuhan.
Tidak semua user yang mengelola konten membutuhkan akses administrator.
Update Sistem Tetap Menjadi Pertahanan Penting
Banyak serangan memanfaatkan celah keamanan yang sebenarnya sudah memiliki patch.
Karena itu, update tetap menjadi bagian penting dari maintenance website.
Komponen yang perlu diperhatikan antara lain:
- CMS;
- plugin;
- theme;
- PHP;
- library;
- web server;
- dependency aplikasi.
Namun update sebaiknya tidak dilakukan secara sembarangan pada website perusahaan.
Lakukan backup terlebih dahulu, uji kompatibilitas bila memungkinkan, kemudian cek fungsi penting setelah proses update selesai.
Website dengan sistem kompleks sebaiknya memiliki staging environment agar perubahan dapat diuji sebelum diterapkan ke production.
Backup Bukan Pencegahan, tetapi Wajib untuk Pemulihan
Backup tidak dapat mencegah hacker masuk.
Namun backup menjadi sangat penting ketika website perlu dipulihkan setelah mengalami malware, kesalahan update, database rusak, atau file terhapus.
Backup sebaiknya mencakup file dan database.
Jangan hanya menyimpan backup pada server yang sama dengan website utama.
Jika server utama terkena serangan, backup yang berada di dalam server yang sama juga berisiko ikut terhapus atau terenkripsi.
Gunakan lokasi backup terpisah seperti object storage atau server backup khusus.
Yang tidak kalah penting, lakukan pengujian restore secara berkala. Backup yang tidak pernah diuji belum tentu dapat dipulihkan saat kondisi darurat.
Monitoring Membantu Mendeteksi Serangan Lebih Cepat
Website yang tampak normal belum tentu benar-benar aman. Beberapa malware bekerja secara tersembunyi dan hanya aktif dalam kondisi tertentu.
Misalnya, script hanya menampilkan halaman spam ketika request berasal dari bot mesin pencari.
Karena itu, administrator perlu memantau beberapa indikator seperti:
- percobaan login gagal berulang;
- perubahan file yang tidak dikenal;
- munculnya user admin baru;
- kenaikan CPU secara tidak normal;
- trafik asing dalam jumlah besar;
- file PHP mencurigakan;
- perubahan DNS;
- redirect tiba-tiba;
- halaman spam yang tidak pernah dibuat.
Monitoring membantu tim mengetahui insiden lebih awal sebelum dampaknya semakin luas.
Checklist Keamanan Website Perusahaan
Untuk memudahkan audit awal, beberapa poin berikut dapat digunakan sebagai checklist:
- WAF aktif;
- Cloudflare security rules dikonfigurasi;
- brute force login dibatasi;
- permission file sudah sesuai;
- wp-config.php terlindungi;
- file editing dashboard dinonaktifkan;
- REST API dibatasi sesuai kebutuhan;
- XML-RPC dinonaktifkan jika tidak digunakan;
- admin menggunakan 2FA;
- akun admin lama sudah dibersihkan;
- CMS dan plugin rutin diperbarui;
- backup tersedia di lokasi berbeda;
- aktivitas website dimonitor.
Checklist tersebut bukan standar keamanan mutlak, tetapi dapat menjadi fondasi awal sebelum menerapkan kontrol yang lebih spesifik.
Keamanan Website Sebaiknya Dibangun Sejak Tahap Development
Mengamankan website setelah semua fitur selesai biasanya lebih sulit dibanding menerapkan standar keamanan sejak awal.
Keamanan sebaiknya sudah menjadi bagian dari proses pengembangan, mulai dari pemilihan teknologi, struktur autentikasi, hak akses user, konfigurasi server, endpoint API, hingga mekanisme backup.
Kebutuhan keamanan setiap website juga berbeda. Company profile sederhana tentu memiliki risiko berbeda dibanding portal member, marketplace, sistem pembayaran, atau aplikasi internal perusahaan.
Karena itu, arsitektur dan kontrol keamanan sebaiknya menyesuaikan fungsi bisnisnya.
Bagi perusahaan yang membutuhkan pengembangan website dengan perhatian pada performa sekaligus aspek keamanan, Ardata Media menyediakan jasa pembuatan website profesional dan aman yang dapat disesuaikan dengan kebutuhan fitur, sistem, dan skala bisnis.
Keamanan website perusahaan sebaiknya dibangun dengan pendekatan berlapis. WAF dan Cloudflare Security Rules dapat digunakan sebagai pertahanan awal, kemudian diperkuat dengan hardening file, pembatasan endpoint, 2FA, serta pengelolaan hak akses yang tepat.
Tidak ada sistem yang bisa dijamin 100% bebas serangan. Namun dengan konfigurasi keamanan yang baik, update rutin, backup terpisah, dan monitoring aktif, risiko website diretas dan dampak yang ditimbulkan dapat ditekan secara signifikan.
