HTTP Security Headers untuk WordPress: Cara Memasang, Menguji, dan Menghindari Kesalahan yang Merusak Iklan AdSense

Sebagian besar pemilik situs WordPress mengira keamanan situs hanya soal kata sandi yang kuat, plugin keamanan, dan cadangan berkala. Padahal ada satu lapisan perlindungan yang bekerja sebelum satu baris JavaScript pun dijalankan di peramban pengunjung: HTTP security headers. Header ini adalah instruksi singkat yang dikirim server bersama setiap halaman, memberi tahu peramban bagaimana ia boleh memuat dan menampilkan konten situs Anda. Tanpa header ini, peramban akan memakai perilaku default yang jauh lebih longgar — dan celah itulah yang dimanfaatkan serangan clickjacking, pencurian data lewat skrip injeksi, hingga downgrade koneksi dari HTTPS ke HTTP.

Bagi publisher Indonesia, taruhannya ganda. Di satu sisi, header yang tepat membuat situs lebih dipercaya peramban dan pengunjung, serta menutup celah serangan yang bisa merusak reputasi situs di mata Google dan pengiklan. Di sisi lain, satu header yang salah — terutama Content Security Policy (CSP) — bisa memblokir skrip iklan AdSense, mematikan Google Tag Manager, atau membuat seluruh situs tidak bisa dibuka. Artikel ini menjelaskan tujuh header yang paling berpengaruh, tiga cara memasangnya di WordPress, dan cara mengujinya dengan aman, termasuk aturan resmi Google soal CSP dan AdSense yang wajib Anda patuhi sebelum menyentuh konfigurasi apa pun.

Poin Kunci

• HTTP security headers adalah instruksi server kepada peramban; tanpa header ini, peramban memakai perilaku default yang lebih rentan terhadap clickjacking, XSS, dan downgrade HTTPS.
• Tujuh header yang paling berpengaruh untuk situs WordPress adalah Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, dan header Cross-Origin (COOP/COEP).
• Server-level (.htaccess untuk Apache atau blok server nginx) adalah cara pemasangan terbaik karena mencakup semua respons, termasuk gambar, CSS, dan JavaScript; cara PHP lewat hook send_headers hanya mencakup respons yang dirender PHP.
• Google secara resmi menyatakan hanya mendukung strict CSP berbasis nonce untuk kode iklan AdSense; pendekatan allowlist domain tidak didukung karena domain yang dipakai AdSense berubah dari waktu ke waktu.
• Uji kebijakan baru dengan header Content-Security-Policy-Report-Only terlebih dahulu, dan naikkan max-age HSTS secara bertahap sebelum mempertimbangkan preload.
• Header yang salah bisa memblokir iklan, merusak tampilan, bahkan mengunci situs dari HTTPS; selalu uji di staging atau di luar jam sibuk, dan simpan cadangan konfigurasi sebelum mengubah apa pun.

Daftar Isi

1. Apa Itu HTTP Security Headers dan Mengapa Publisher WordPress Perlu Memahaminya
2. Tujuh Header yang Paling Berpengaruh untuk Situs WordPress
3. Cara Memeriksa Header yang Sudah Aktif di Situs Anda
4. Tiga Cara Memasang Security Headers di WordPress
5. CSP dan AdSense: Bagian Paling Rawan Salah
6. Lima Kesalahan Umum yang Merusak Situs
7. Cara Menguji dan Memantau Setelah Pemasangan
8. Checklist Penerapan Bertahap dalam Tujuh Hari
9. FAQ
10. Kesimpulan

1. Apa Itu HTTP Security Headers dan Mengapa Publisher WordPress Perlu Memahaminya

Setiap kali seseorang membuka halaman situs Anda, server mengirim dua hal: header HTTP dan badan halaman (HTML). Header HTTP berisi metadata — jenis konten, instruksi cache, cookie, dan lain-lain — yang dibaca peramban sebelum ia mulai merender halaman. Security headers adalah sekelompok header HTTP yang secara khusus memberi tahu peramban aturan keamanan apa yang harus ditegakkan saat memuat halaman tersebut.

Contohnya sederhana. Header X-Frame-Options: DENY memberi tahu peramban: jangan pernah menampilkan halaman ini di dalam frame atau iframe situs lain. Tanpa header itu, situs Anda bisa disematkan secara diam-diam di halaman penyerang, lalu tombol atau formulir Anda ditumpuk di bawah lapisan transparan sehingga pengunjung mengklik sesuatu yang tidak mereka sadari — serangan yang dikenal sebagai clickjacking. Header Strict-Transport-Security memberi tahu peramban: situs ini hanya boleh diakses lewat HTTPS, jadi jangan pernah lagi mencoba HTTP. Tanpa header itu, penyerang di jaringan yang sama (misalnya Wi-Fi publik) bisa mencoba menurunkan koneksi pengunjung dari HTTPS ke HTTP dan mengintip atau memodifikasi lalu lintas.

Yang membuat header ini penting bagi publisher WordPress adalah tiga hal. Pertama, header bekerja di sisi peramban, sehingga melindungi pengunjung bahkan ketika plugin keamanan atau firewall Anda tidak melihat serangan itu — serangan terjadi di peramban korban, bukan di server Anda. Kedua, header tidak memerlukan plugin berat atau biaya tambahan; sebagian besar bisa dipasang dengan beberapa baris konfigurasi di server atau di functions.php. Ketiga, header yang tepat mengurangi risiko insiden keamanan yang berujung pada peringatan peramban, penurunan kepercayaan pengunjung, dan potensi masalah dengan kebijakan iklan — pengiklan dan jaringan iklan menilai keamanan situs sebagai bagian dari kualitas inventaris.

Namun ada sisi lain yang sama pentingnya: header adalah pedang bermata dua. Header yang terlalu ketat atau salah konfigurasi bisa memblokir sumber daya yang sah — skrip analitik, font dari CDN, video YouTube yang disematkan, dan yang paling fatal bagi publisher, skrip iklan AdSense. Karena itu artikel ini tidak sekadar memberi contoh salin-tempel; setiap header dijelaskan beserta risikonya, dan ada bagian khusus tentang CSP dan AdSense yang bersumber langsung dari dokumentasi resmi Google.

Perlu juga dipahami batasan header ini. OWASP Secure Headers Project menegaskan bahwa header keamanan berlaku untuk agen pengguna berupa peramban; header bukan pengganti perbaikan kode yang rentan, bukan pengganti pembaruan WordPress dan plugin, dan bukan pengganti cadangan. Header menutup celah di sisi peramban, tetapi tidak memperbaiki celah injeksi SQL, tidak menambal plugin yang kedaluwarsa, dan tidak menghentikan serangan brute force terhadap halaman login. Anggap header sebagai satu lapis dari pertahanan berlapis, bukan sebagai benteng tunggal.

2. Tujuh Header yang Paling Berpengaruh untuk Situs WordPress

Tidak semua header sama pentingnya. Daftar di bawah ini adalah tujuh header yang paling berpengaruh untuk situs WordPress milik publisher, diurutkan dari yang dampaknya paling besar. Tabel berikut merangkum fungsi masing-masing sebelum kita bahas satu per satu.

2.1 Strict-Transport-Security (HSTS)

HSTS adalah mekanisme yang didefinisikan dalam RFC 6797. Cara kerjanya: setelah peramban pertama kali mengunjungi situs Anda lewat HTTPS dan menerima header ini, peramban akan mengingat bahwa situs Anda hanya boleh diakses lewat HTTPS selama periode yang ditentukan oleh max-age (dalam detik), dan secara otomatis menaikkan setiap permintaan HTTP menjadi HTTPS — tanpa perlu pengalihan dari server. Ini melindungi pengunjung dari serangan SSL stripping, yaitu upaya penyerang menurunkan koneksi ke HTTP di tengah jalan.

Satu hal penting yang ditegaskan MDN dan OWASP: header HSTS yang dikirim lewat koneksi HTTP diabaikan oleh peramban. Header ini hanya berpengaruh bila dikirim lewat HTTPS. Karena itu, HSTS hanya berguna bila situs Anda sudah sepenuhnya HTTPS — semua halaman, aset, dan subdomain yang tercakup.

Nilai max-age yang umum dipakai adalah 31536000 (satu tahun dalam detik) atau 63072000 (dua tahun). Direktif includeSubDomains memperluas kebijakan ke semua subdomain. Direktif preload menyatakan bahwa Anda ingin domain didaftarkan ke daftar preload HSTS yang tertanam di peramban — tetapi jangan menambahkan preload sembarangan. Pendaftaran preload bersifat sulit dibatalkan: begitu domain masuk daftar, peramban akan memaksa HTTPS bahkan sebelum kunjungan pertama, dan bila suatu hari sertifikat SSL Anda bermasalah atau Anda perlu kembali ke HTTP, pengunjung tidak akan bisa membuka situs sama sekali sampai domain dikeluarkan dari daftar — proses yang memakan waktu berminggu-minggu. Aturan praktisnya: jalankan HSTS dengan max-age kecil (misalnya 300 detik, lalu 86400, lalu 31536000) selama beberapa minggu, pastikan tidak ada lagi konten HTTP, dan baru pertimbangkan preload bila Anda yakin HTTPS akan permanen.

2.2 Content-Security-Policy (CSP)

CSP adalah header yang paling kuat sekaligus paling rumit. Header ini mendefinisikan sumber mana saja yang boleh memuat skrip, gaya, gambar, font, dan sumber daya lain di halaman Anda. Bila penyerang berhasil menyuntikkan skrip berbahaya ke halaman Anda — misalnya lewat komentar atau kolom yang tidak tervalidasi — CSP yang ketat akan membuat peramban menolak menjalankan skrip itu karena sumbernya tidak ada dalam daftar yang diizinkan.

CSP disusun dari direktif-direktif. Beberapa yang paling sering dipakai:

• default-src 'self' — sumber default untuk semua jenis konten adalah domain sendiri.
• script-src — sumber skrip JavaScript yang diizinkan.
• style-src — sumber stylesheet yang diizinkan.
• img-src — sumber gambar yang diizinkan.
• font-src — sumber font yang diizinkan.
• connect-src — sumber untuk permintaan XHR, Fetch, dan WebSocket.
• frame-src — sumber yang boleh dimuat di dalam frame atau iframe.
• object-src 'none' — melarang plugin seperti Flash dan objek tertanam lainnya.
• base-uri 'self' — membatasi elemen <base> agar tidak bisa dialihkan ke domain lain.
• frame-ancestors 'none' — melarang halaman Anda disematkan di frame situs mana pun; ini adalah pengganti modern untuk X-Frame-Options.
• form-action 'self' — membatasi ke mana formulir boleh dikirim.
• upgrade-insecure-requests — meminta peramban menaikkan permintaan HTTP menjadi HTTPS secara otomatis.

Nilai 'self' berarti domain yang sama dengan halaman. Nilai 'none' berarti tidak ada sumber yang diizinkan. Nilai 'unsafe-inline' mengizinkan skrip dan gaya inline — tetapi mengizinkan ini melemahkan perlindungan CSP secara signifikan, karena skrip injeksi umumnya juga berbentuk inline. Karena itu, kebijakan yang baik meminimalkan 'unsafe-inline' dan sedapat mungkin memindahkan skrip inline ke berkas eksternal atau memakai nonce.

Bagian tersulit dari CSP adalah inventarisasi: sebelum menegakkan kebijakan, Anda harus tahu semua sumber daya pihak ketiga yang dipakai situs Anda — iklan AdSense, Google Analytics, Google Tag Manager, font Google, CDN, penyedia video, dan widget lain. Satu domain yang tertinggal dari daftar berarti sumber daya itu diblokir. Inilah sebabnya Google menyarankan menguji kebijakan dengan mode Report-Only terlebih dahulu (dibahas di bagian 5), dan mengapa CSP dan AdSense membutuhkan perhatian khusus.

2.3 X-Frame-Options

Header ini mengontrol apakah halaman Anda boleh ditampilkan di dalam <frame>, <iframe>, atau <object> di situs lain. Ada dua nilai yang masih relevan: DENY (tidak boleh di-frame oleh siapa pun) dan SAMEORIGIN (hanya boleh di-frame oleh halaman dari domain yang sama). Nilai ketiga, ALLOW-FROM, sudah tidak didukung peramban modern dan sebaiknya tidak dipakai.

Untuk sebagian besar situs publisher, SAMEORIGIN adalah pilihan yang aman: halaman Anda tetap bisa disematkan oleh halaman Anda sendiri bila diperlukan, tetapi tidak bisa disematkan oleh situs penyerang. OWASP mencatat bahwa direktif CSP frame-ancestors kini menggantikan X-Frame-Options; bila sebuah respons membawa keduanya, kebijakan frame-ancestors yang ditegakkan dan X-Frame-Options diabaikan. Praktik yang dianjurkan adalah memasang keduanya — X-Frame-Options untuk peramban lama, frame-ancestors untuk peramban modern — dengan nilai yang konsisten agar tidak terjadi kebingungan.

2.4 X-Content-Type-Options

Header ini hanya punya satu nilai yang valid: nosniff. Fungsinya mencegah peramban menebak-nebak (MIME sniffing) tipe konten sebuah berkas. Tanpa header ini, peramban bisa saja memperlakukan berkas teks biasa sebagai JavaScript bila isinya tampak seperti skrip — celah yang pernah dipakai untuk menjalankan skrip berbahaya yang diunggah sebagai berkas yang tampak tidak berbahaya, misalnya lewat kolom unggahan atau avatar.

Header ini tergolong rendah risiko: hampir tidak ada efek samping bila dipasang dengan benar, selama server Anda menyajikan tipe konten yang benar untuk skrip dan stylesheet. Bila ada berkas CSS atau JavaScript yang disajikan dengan tipe konten yang salah, header ini justru akan membuat peramban menolak memuatnya — yang sebenarnya membantu Anda menemukan kesalahan konfigurasi server.

2.5 Referrer-Policy

Header ini mengatur informasi apa yang dikirim peramban di header Referer saat pengunjung mengeklik tautan dari situs Anda ke situs lain. Tanpa kebijakan ini, peramban mengirim URL lengkap halaman asal — termasuk parameter query yang mungkin sensitif, misalnya token atau kata kunci pencarian internal. Nilai yang umum dianjurkan adalah strict-origin-when-cross-origin: saat berpindah ke situs lain, hanya domain asal yang dikirim (bukan URL lengkap), dan saat berpindah dari HTTPS ke HTTP, tidak ada referrer yang dikirim sama sekali.

Nilai lain yang mungkin Anda temui: no-referrer (tidak pernah mengirim referrer), same-origin (hanya mengirim referrer ke domain yang sama), dan strict-origin (hanya mengirim domain asal, untuk semua tujuan). Untuk situs publisher, strict-origin-when-cross-origin adalah keseimbangan yang baik: analitik dan program afiliasi tetap bisa melihat asal kunjungan, tetapi detail URL tidak bocor ke pihak ketiga.

2.6 Permissions-Policy

Permissions-Policy adalah pengganti Feature-Policy yang lebih lama. Header ini mengontrol fitur peramban apa saja yang boleh dipakai halaman Anda — kamera, mikrofon, geolokasi, sensor gerak, dan lain-lain. Sintaksnya berupa daftar fitur dengan nilai dalam tanda kurung, misalnya camera=(), microphone=(), geolocation=() yang berarti ketiga fitur itu dinonaktifkan untuk halaman Anda dan untuk iframe yang disematkan.

Untuk situs berita atau blog yang tidak memakai kamera dan mikrofon, menonaktifkan fitur-fitur ini adalah langkah yang murah dan aman: bila suatu hari ada skrip pihak ketiga yang mencoba mengakses fitur tersebut, peramban akan menolaknya. Daftar fitur yang tersedia terus berkembang, jadi periksa dokumentasi MDN untuk daftar terbaru sebelum menambahkan fitur yang tidak Anda kenali.

2.7 Cross-Origin-Opener-Policy dan Cross-Origin-Embedder-Policy

Dua header ini bekerja berpasangan untuk mengisolasi halaman Anda dari konteks penelusuran lain — misalnya jendela popup atau tab lain yang dibuka dari situs Anda. Cross-Origin-Opener-Policy: same-origin memastikan halaman yang dibuka dari situs Anda tidak bisa mengakses objek window halaman Anda, menutup celah serangan cross-origin klasik. Cross-Origin-Embedder-Policy: require-corp meminta semua sumber daya lintas origin dimuat dengan perlindungan CORS yang eksplisit.

Kedua header ini lebih relevan untuk aplikasi web yang menangani data sensitif atau memakai fitur seperti SharedArrayBuffer. Untuk situs publisher biasa, keduanya bersifat opsional dan berisiko memblokir sumber daya lintas origin yang tidak dikonfigurasi CORS dengan benar — termasuk beberapa widget iklan dan analitik. Bila Anda tidak yakin, pasang lima header pertama terlebih dahulu, dan perlakukan COOP/COEP sebagai langkah lanjutan setelah Anda memahami inventaris sumber daya pihak ketiga di situs Anda.

Satu header yang sebaiknya tidak Anda pasang lagi adalah X-XSS-Protection. Header ini dulunya mengaktifkan filter XSS bawaan peramban, tetapi peramban modern sudah menghapus atau menonaktifkan filter tersebut, dan MDN menyatakan perlindungan ini sebagian besar tidak diperlukan bila Anda sudah memakai CSP yang kuat. Memasang X-XSS-Protection: 1; mode=block pada peramban lama justru bisa menimbulkan perilaku yang tidak diinginkan, sehingga panduan modern menganjurkannya untuk tidak dipakai.

3. Cara Memeriksa Header yang Sudah Aktif di Situs Anda

Sebelum menambahkan header apa pun, periksa dulu apa yang sudah dikirim server Anda saat ini. Banyak hosting — termasuk hosting bersama yang populer di Indonesia — sudah mengirim sebagian header secara default, dan beberapa plugin keamanan juga sudah menambahkan headernya sendiri. Menambahkan header yang sama dua kali bisa menimbulkan duplikasi yang membingungkan peramban dan alat penguji.

3.1 Memeriksa dengan curl

Cara paling cepat dan dapat diandalkan adalah perintah curl dari terminal atau dari layanan terminal daring. Perintah berikut meminta header respons dari halaman utama situs Anda:

curl -sI https://contoh.com

Perintah -I meminta server hanya mengirim header (tanpa badan halaman). Perhatikan baris-baris seperti strict-transport-security, content-security-policy, x-frame-options, dan x-content-type-options. Bila tidak ada satu pun dari baris itu, berarti situs Anda belum mengirim header keamanan. Ulangi pemeriksaan pada satu artikel dan satu halaman yang memuat iklan, karena sebagian konfigurasi hanya berlaku untuk jenis halaman tertentu.

Untuk memeriksa header dari berkas statis — misalnya gambar atau stylesheet — arahkan curl ke URL berkas tersebut. Bila Anda memasang header lewat PHP, Anda akan menemukan bahwa berkas statis tidak membawa header itu, karena berkas statis disajikan langsung oleh server web tanpa melewati PHP. Inilah alasan mengapa pemasangan di level server lebih disukai.

3.2 Memeriksa dengan DevTools peramban

Buka situs Anda di Chrome atau Firefox, tekan F12, lalu buka tab Network dan muat ulang halaman. Klik permintaan pertama (biasanya dokumen HTML utama) dan lihat bagian Response Headers. Cara ini berguna untuk memeriksa header pada halaman yang sudah login atau halaman yang memerlukan interaksi, dan untuk melihat apakah ada header yang hanya muncul pada respons tertentu.

3.3 Memeriksa dengan alat pemindai daring

Alat pemindai seperti securityheaders.com (dari Scott Helme) memindai situs Anda dan memberi nilai huruf beserta penjelasan untuk setiap header yang hilang atau salah konfigurasi. Alat semacam ini berguna sebagai titik awal, tetapi jangan mengejar nilai sempurna secara membabi buta: nilai A+ yang dicapai dengan CSP yang terlalu ketat bisa berarti iklan Anda diblokir. Gunakan hasil pemindaian sebagai daftar periksa, bukan sebagai target mutlak.

Catat hasil pemeriksaan awal Anda — header mana yang sudah ada, header mana yang hilang, dan apakah ada duplikasi. Catatan ini menjadi dasar perbandingan setelah Anda memasang header baru.

4. Tiga Cara Memasang Security Headers di WordPress

Ada tiga jalur utama memasang header di WordPress: konfigurasi server (Apache .htaccess atau blok server nginx), kode PHP lewat hook WordPress, dan plugin. Masing-masing punya kelebihan dan kekurangan, dan pilihan yang tepat bergantung pada akses yang Anda miliki ke server.

Aturan yang wajib diingat: pakai satu cara saja untuk setiap header. Bila Anda memasang header yang sama lewat server dan lewat plugin, peramban menerima header itu dua kali dengan nilai yang bisa berbeda, dan hasilnya tidak dapat diprediksi. Pilih satu jalur, dan matikan jalur lainnya untuk header yang sama.

4.1 Cara server Apache: .htaccess

Bila situs Anda berjalan di Apache — seperti kebanyakan hosting bersama — Anda bisa menambahkan header di berkas .htaccess di direktori root WordPress. Contoh konfigurasi awal yang aman untuk situs publisher:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS
</IfModule>

Perhatikan beberapa hal. Direktif env=HTTPS pada HSTS memastikan header hanya dikirim lewat koneksi HTTPS, sesuai aturan bahwa HSTS lewat HTTP diabaikan. CSP sengaja tidak ada dalam contoh ini, karena CSP membutuhkan inventarisasi sumber daya pihak ketiga terlebih dahulu dan dibahas tersendiri di bagian 5. Jangan pernah menyalin konfigurasi CSP dari situs lain tanpa menyesuaikannya dengan sumber daya yang dipakai situs Anda.

Sebelum menyimpan perubahan, buat cadangan berkas .htaccess yang lama. Satu kesalahan sintaks di berkas ini bisa membuat seluruh situs menampilkan error 500. Setelah menyimpan, segera periksa situs dengan curl dan buka beberapa halaman di peramban. Bila situs menampilkan error, kembalikan berkas cadangan.

4.2 Cara server nginx

Bila server Anda memakai nginx, header ditambahkan di dalam blok server pada konfigurasi situs, misalnya:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Kata kunci always memastikan header dikirim untuk semua kode status respons, bukan hanya respons sukses. Setelah mengubah konfigurasi, uji sintaks dengan nginx -t sebelum me-reload layanan — ini mencegah server gagal start karena kesalahan tulis. Perlu diingat bahwa di nginx, direktif add_header di blok turunan (misalnya di dalam location) akan menggantikan seluruh header dari blok induk, bukan menambahkannya. Bila Anda memakai blok location dengan add_header sendiri, salin semua header yang diperlukan ke dalam blok tersebut.

4.3 Cara PHP: hook send_headers dan filter wp_headers

Bila Anda tidak punya akses ke konfigurasi server, atau memakai hosting yang tidak mengizinkan pengubahan .htaccess, Anda bisa menambahkan header lewat PHP. WordPress menyediakan dua hook untuk keperluan ini: action send_headers dan filter wp_headers. Keduanya sudah ada sejak WordPress 2.8. Action send_headers berjalan sebelum header dikirim dan mencakup area admin, sedangkan filter wp_headers memodifikasi larik header untuk halaman front-end.

Contoh memakai action send_headers di functions.php tema anak:

add_action( 'send_headers', 'bangeko_tambah_security_headers' );
function bangeko_tambah_security_headers() {
    header( 'X-Content-Type-Options: nosniff' );
    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=()' );
    if ( is_ssl() ) {
        header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
    }
}

Gunakan tema anak, bukan tema utama, agar perubahan tidak hilang saat tema diperbarui. Perlu dicatat keterbatasan penting cara ini: header yang dipasang lewat PHP hanya berlaku untuk respons yang dirender oleh PHP. Gambar, CSS, dan JavaScript yang disajikan langsung dari disk tidak akan membawa header tersebut. Untuk situs publisher yang sebagian besar asetnya statis, ini berarti cakupan perlindungannya tidak lengkap — tetapi tetap lebih baik daripada tidak ada header sama sekali, dan cara ini berguna untuk pengujian sebelum Anda memindahkan kebijakan ke level server.

4.4 Cara plugin

Beberapa plugin keamanan dan plugin khusus security headers menyediakan antarmuka untuk mengaktifkan header tanpa menulis kode. Cara ini paling mudah bagi pemilik situs yang tidak nyaman mengedit berkas server. Kelemahannya: menambah satu plugin lagi berarti menambah permukaan pemeliharaan, dan sebagian plugin menambahkan header dengan nilai default yang mungkin tidak cocok dengan situs Anda — terutama CSP bawaan yang bisa memblokir iklan.

Bila Anda memilih jalur plugin, baca setiap nilai default yang akan diterapkan sebelum mengaktifkannya, dan periksa setelahnya dengan curl bahwa tidak ada header yang terduplikasi dengan konfigurasi server Anda. Bila hosting Anda sudah mengirim header tertentu, matikan header yang sama di plugin.

5. CSP dan AdSense: Bagian Paling Rawan Salah

Bagian ini adalah bagian terpenting bagi publisher AdSense, dan sumbernya adalah dokumentasi resmi Google. Google menyatakan dengan jelas dalam panduan "Integrate the AdSense ad code with a Content Security Policy": publisher tidak wajib memakai CSP, tetapi bila memakai CSP, kebijakan tersebut harus mematuhi panduan Google. Kegagalan melakukannya dapat mengakibatkan gangguan penayangan iklan di situs Anda.

5.1 Google hanya mendukung strict CSP berbasis nonce

Ada dua pendekatan standar dalam menyusun CSP: daftar domain yang diizinkan (allowlist) dan nonce acak yang ditempelkan pada setiap tag skrip (strict CSP). Google menyatakan secara eksplisit bahwa mereka hanya mendukung strict CSP, karena domain yang dipakai kode iklan AdSense berubah dari waktu ke waktu — daftar domain yang Anda tulis hari ini bisa kedaluwarsa tanpa pemberitahuan, dan iklan Anda akan berhenti tampil.

Contoh kebijakan yang didukung AdSense menurut dokumentasi Google adalah:

Content-Security-Policy: object-src 'none';
    script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
    base-uri 'none';
    report-uri https://your-report-collector.example.com/

Perhatikan bahwa nilai 'nonce-{random}' harus diganti dengan nonce acak yang berbeda untuk setiap respons, dan setiap tag <script> di halaman — termasuk kode AdSense — harus membawa atribut nonce yang sama. Tanpa nonce yang cocok, peramban akan memblokir skrip tersebut. Ini berarti strict CSP bukan sekadar satu baris konfigurasi server: ia membutuhkan perubahan pada cara tema dan plugin Anda mengeluarkan tag skrip, dan sebagian besar tema WordPress tidak menghasilkan nonce secara bawaan. Bagi sebagian besar publisher kecil, pesan praktisnya adalah: jangan menegakkan CSP yang ketat sebelum Anda memahami cara kerja nonce di tema Anda, atau sebelum Anda memakai plugin yang memang dirancang untuk menghasilkan nonce.

5.2 Uji dulu dengan mode Report-Only

Google merekomendasikan pengujian kebijakan dengan header Content-Security-Policy-Report-Only sebelum menegakkan kebijakan yang sesungguhnya. Dalam mode ini, peramban tidak memblokir apa pun — ia hanya mencatat pelanggaran yang akan terjadi bila kebijakan itu ditegakkan, dan mengirim laporan ke alamat yang Anda tentukan lewat direktif report-uri atau report-to. Jalankan mode Report-Only selama minimal satu sampai dua minggu, pantau laporan pelanggaran, dan perbaiki daftar sumber yang hilang sebelum beralih ke mode penegakan.

Selama masa pengujian, periksa halaman-halaman yang berbeda: beranda, artikel dengan iklan display, artikel dengan iklan in-feed, halaman dengan video tersemat, dan halaman dengan formulir. Iklan AdSense memuat sumber daya dari banyak domain dan dalam pola yang berubah-ubah, sehingga pelanggaran yang tidak muncul di beranda bisa muncul di halaman artikel.

5.3 Kesalahan CSP yang paling sering memblokir iklan

Tiga kesalahan ini paling sering dilaporkan publisher yang iklannya tiba-tiba berhenti tampil setelah memasang CSP:

Pertama, default-src 'self' tanpa pengecualian untuk domain Google. Kebijakan ini memblokir semua skrip dari luar domain Anda, termasuk pagead2.googlesyndication.com tempat skrip AdSense dimuat. Bila Anda memakai pendekatan allowlist — yang tidak didukung Google — Anda harus menambahkan puluhan domain Google yang berubah-ubah, dan pendekatan ini tetap rapuh.

Kedua, script-src 'self' tanpa 'unsafe-inline' pada situs yang masih memakai skrip inline. Banyak tema dan plugin WordPress mengeluarkan skrip inline, dan memblokirnya sekaligus bisa merusak tampilan, menu, dan fungsi interaktif situs. Solusinya bukan menambah 'unsafe-inline' secara permanen tanpa pikir panjang, melainkan memindahkan skrip inline ke berkas eksternal atau beralih ke nonce.

Ketiga, lupa menambahkan frame-src untuk domain iklan. Iklan AdSense dirender di dalam iframe dari domain seperti googleads.g.doubleclick.net dan tpc.googlesyndication.com. Kebijakan CSP yang membatasi frame-src hanya ke 'self' akan membuat slot iklan tampil kosong. Sekali lagi, pendekatan allowlist domain seperti ini bukan pendekatan yang didukung Google — pendekatan yang didukung adalah strict CSP dengan nonce.

5.4 Urutan yang aman untuk publisher

Bila Anda menjalankan AdSense dan ingin memakai CSP, ikuti urutan ini: pertama, pasang lima header lain (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) dan pastikan situs stabil selama beberapa hari. Kedua, susun kebijakan CSP dalam mode Report-Only dan pantau laporan pelanggaran selama satu sampai dua minggu. Ketiga, bila Anda memakai pendekatan allowlist, sadari bahwa Google tidak mendukungnya dan iklan Anda berisiko terganggu saat domain Google berubah; pendekatan yang didukung adalah strict CSP dengan nonce, yang membutuhkan dukungan tema atau plugin. Keempat, bila Anda ragu, tidak memasang CSP sama sekali adalah pilihan yang sah — Google sendiri menyatakan publisher tidak wajib memakai CSP, dan lima header lain sudah memberikan perlindungan yang berarti tanpa risiko memblokir iklan.

6. Lima Kesalahan Umum yang Merusak Situs

6.1 Mendaftarkan HSTS preload terlalu cepat

Preload HSTS adalah keputusan yang sulit dibatalkan. Daftar preload tertanam di dalam peramban itu sendiri, dan penghapusan dari daftar membutuhkan pengajuan serta waktu tunggu berminggu-minggu. Selama masa itu, pengunjung yang perambannya sudah mengunduh daftar tersebut tidak akan bisa membuka situs Anda lewat HTTP sama sekali. Jangan menambahkan direktif preload atau mengajukan domain ke daftar preload sebelum Anda menjalankan HSTS dengan max-age penuh selama beberapa minggu, memastikan semua subdomain sudah HTTPS, dan memastikan sertifikat SSL Anda diperbarui secara otomatis. Untuk sebagian besar situs publisher, HSTS tanpa preload sudah memberikan hampir semua manfaatnya.

6.2 Menyalin CSP dari situs lain tanpa penyesuaian

Contoh kebijakan CSP yang beredar di internet disusun untuk situs yang sumber dayanya berbeda dengan situs Anda. Kebijakan yang dibuat untuk situs statis tanpa iklan akan memblokir AdSense di situs Anda. Kebijakan yang dibuat untuk situs dengan Google Tag Manager mungkin tetap memblokir widget obrolan atau pemutar video yang Anda pakai. CSP adalah kebijakan yang bersifat spesifik per situs: susun dari inventaris sumber daya Anda sendiri, uji dalam mode Report-Only, dan jangan pernah menegakkan kebijakan yang Anda salin mentah-mentah.

6.3 Mengirim header yang sama dua kali

Duplikasi terjadi ketika header dipasang di dua tempat sekaligus — misalnya HSTS di .htaccess dan juga di plugin keamanan, atau X-Frame-Options di nginx dan juga di functions.php. Peramban yang menerima header yang sama dua kali dengan nilai berbeda akan memakai salah satunya atau menggabungkannya, dan hasilnya tidak dapat diprediksi. Setelah memasang header, selalu periksa dengan curl apakah ada header yang muncul dua kali, dan matikan salah satu sumbernya.

6.4 Memakai nilai yang sudah tidak didukung

Beberapa nilai header sudah ditinggalkan peramban modern. X-Frame-Options: ALLOW-FROM tidak didukung peramban modern — pakai SAMEORIGIN atau CSP frame-ancestors sebagai gantinya. X-XSS-Protection sudah tidak lagi memberi manfaat di peramban modern dan sebaiknya tidak dipasang. Feature-Policy sudah digantikan oleh Permissions-Policy dengan sintaks yang berbeda; memakai nama header lama tidak akan berpengaruh apa-apa. Periksa dokumentasi MDN secara berkala, karena daftar header yang didukung berubah seiring pembaruan peramban.

6.5 Lupa bahwa perubahan header tidak berlaku surut

Header HSTS disimpan di peramban pengunjung selama max-age yang Anda tentukan. Bila Anda memasang HSTS dengan max-age satu tahun lalu menyadari ada subdomain yang masih HTTP, pengunjung yang sudah menerima header itu akan dipaksa memakai HTTPS untuk subdomain tersebut selama satu tahun — meskipun Anda sudah menghapus header dari server. Inilah alasan mengapa max-age harus dinaikkan secara bertahap: mulai dari 300 detik, lalu 86400 (satu hari), lalu 604800 (satu minggu), dan baru kemudian 31536000 (satu tahun). Setiap kenaikan hanya dilakukan setelah Anda yakin tidak ada lagi konten HTTP yang tersisa.

7. Cara Menguji dan Memantau Setelah Pemasangan

Pemasangan header bukan pekerjaan sekali selesai. Pengujian dan pemantauan berkala memastikan header tetap berfungsi saat tema diperbarui, plugin diganti, atau hosting mengubah konfigurasi server.

7.1 Pengujian segera setelah pemasangan

Segera setelah memasang header, lakukan tiga pemeriksaan. Pertama, periksa dengan curl bahwa header terkirim pada halaman utama, satu artikel, dan satu berkas statis. Kedua, buka situs di peramban dan periksa tab Console di DevTools: pelanggaran CSP akan muncul sebagai pesan error di sana, lengkap dengan sumber daya yang diblokir dan direktif yang dilanggar. Ketiga, periksa fungsi situs secara menyeluruh: menu, formulir komentar, pemutar video, dan yang terpenting, slot iklan AdSense — pastikan iklan tampil normal dan tidak ada slot kosong yang sebelumnya terisi.

7.2 Pengujian dengan alat pemindai

Jalankan pemindaian di securityheaders.com dan catat nilainya. Bandingkan dengan hasil pemindaian sebelum pemasangan. Bila ada header yang masih dilaporkan hilang, periksa apakah header itu memang tidak terkirim atau hanya tidak terkirim pada jenis respons tertentu. Perlu diingat bahwa alat pemindai memeriksa halaman utama; header yang dipasang lewat PHP mungkin tidak muncul pada berkas statis, dan alat pemindai tidak selalu memeriksa berkas statis tersebut.

7.3 Pemantauan berkelanjutan

Jadwalkan pemeriksaan ulang setiap kali Anda melakukan perubahan besar: pergantian tema, pemasangan plugin baru, migrasi hosting, atau perubahan pada konfigurasi server. Perubahan-perubahan ini bisa menghapus atau menimpa konfigurasi header Anda tanpa pemberitahuan. Untuk CSP, pantau laporan pelanggaran dari direktif report-uri atau report-to secara berkala; lonjakan laporan pelanggaran sering kali menandakan ada plugin baru yang memuat skrip dari domain yang belum ada dalam kebijakan.

Bila situs Anda memakai layanan pemantauan uptime atau pemantauan keamanan, periksa apakah layanan tersebut bisa memantau header respons. Beberapa layanan memungkinkan Anda menetapkan pemeriksaan kustom yang memperingatkan bila header tertentu hilang dari respons.

8. Checklist Penerapan Bertahap dalam Tujuh Hari

Penerapan yang aman dilakukan bertahap, bukan sekaligus. Berikut urutan yang dianjurkan:

• Hari 1 — Periksa dan cadangkan. Periksa header yang sudah aktif dengan curl, catat hasilnya, dan buat cadangan berkas .htaccess atau konfigurasi server serta functions.php tema anak.
• Hari 2 — Pasang lima header dasar. Tambahkan X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, dan HSTS dengan max-age kecil (300 detik) lewat satu jalur pemasangan saja.
• Hari 3 — Uji fungsi situs. Periksa iklan AdSense, formulir, menu, video tersemat, dan halaman-halaman utama. Perbaiki bila ada yang rusak.
• Hari 4 — Naikkan max-age HSTS. Bila tidak ada masalah, naikkan max-age menjadi 86400, lalu 604800 dalam beberapa hari berikutnya.
• Hari 5 — Susun CSP dalam mode Report-Only. Buat inventaris sumber daya pihak ketiga, susun kebijakan, dan aktifkan sebagai Content-Security-Policy-Report-Only.
• Hari 6–14 — Pantau laporan CSP. Biarkan mode Report-Only berjalan, perbaiki daftar sumber yang hilang, dan jangan menegakkan kebijakan sebelum laporan pelanggaran bersih.
• Hari 15 — Evaluasi. Bila laporan bersih dan Anda memahami cara kerja nonce di tema Anda, pertimbangkan penegakan strict CSP. Bila tidak, biarkan CSP tetap dalam mode Report-Only atau tidak dipasang sama sekali — lima header lain sudah memberikan perlindungan yang berarti.

FAQ

Apakah HTTP security headers memengaruhi SEO?

Header keamanan bukan faktor peringkat langsung, tetapi berdampak tidak langsung. Situs yang aman lebih dipercaya pengunjung dan pengiklan, dan HSTS mendukung HTTPS penuh yang memang dipakai Google sebagai sinyal peringkat. Sebaliknya, header yang salah bisa merusak SEO: CSP yang memblokir skrip analitik membuat data kunjungan hilang, dan HSTS yang salah konfigurasi bisa membuat situs tidak bisa diakses sama sekali.

Apakah saya perlu plugin untuk memasang security headers di WordPress?

Tidak. Header bisa dipasang lewat konfigurasi server (.htaccess atau nginx) atau lewat kode PHP di functions.php tema anak dengan hook send_headers. Plugin hanya memudahkan pengaturan bagi yang tidak nyaman mengedit berkas. Bila memakai plugin, pastikan tidak ada duplikasi dengan konfigurasi server.

Mengapa iklan AdSense saya hilang setelah memasang CSP?

Penyebab paling umum adalah kebijakan CSP yang memblokir domain atau skrip AdSense. Google hanya mendukung strict CSP berbasis nonce untuk kode iklannya; pendekatan allowlist domain tidak didukung karena domain yang dipakai AdSense berubah dari waktu ke waktu. Kembalikan kebijakan ke mode Report-Only, periksa pesan pelanggaran di Console DevTools, dan ikuti panduan resmi Google sebelum menegakkan kebijakan lagi.

Berapa lama waktu yang dibutuhkan peramban untuk melupakan HSTS?

Peramban mengingat kebijakan HSTS selama max-age yang Anda tentukan, dihitung sejak terakhir kali header diterima. Bila max-age Anda satu tahun, pengunjung yang sudah menerima header itu akan dipaksa memakai HTTPS selama satu tahun, meskipun Anda menghapus header dari server. Karena itu naikkan max-age secara bertahap dan pastikan seluruh situs sudah HTTPS sebelum memakai nilai besar.

Apakah X-Frame-Options masih diperlukan bila saya sudah memakai CSP frame-ancestors?

Untuk peramban modern, frame-ancestors sudah cukup dan menggantikan X-Frame-Options. Namun memasang keduanya dengan nilai yang konsisten tetap dianjurkan untuk mencakup peramban lama yang belum mendukung CSP frame-ancestors. Pastikan nilai keduanya selaras: bila CSP memakai frame-ancestors 'none', X-Frame-Options sebaiknya DENY.

Apakah header keamanan melindungi situs dari serangan brute force dan injeksi SQL?

Tidak. Header keamanan melindungi peramban pengunjung dari serangan seperti clickjacking dan XSS. Serangan brute force terhadap halaman login, injeksi SQL, dan eksploitasi plugin rentan harus ditangani dengan langkah lain: kata sandi kuat dan autentikasi dua faktor, pembaruan WordPress dan plugin, pembatasan percobaan login, dan cadangan berkala. Header adalah satu lapis pertahanan, bukan pengganti langkah-langkah tersebut.

Kesimpulan

HTTP security headers adalah lapisan perlindungan yang murah, ringan, dan bekerja di sisi peramban — tempat sebagian serangan terhadap pengunjung Anda benar-benar terjadi. Lima header dasar — HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, dan Permissions-Policy — bisa dipasang dalam satu hari dengan risiko yang kecil, asalkan Anda memilih satu jalur pemasangan, membuat cadangan sebelum mengubah konfigurasi, dan menguji fungsi situs setelahnya, terutama slot iklan.

Content Security Policy adalah pengecualian yang membutuhkan kehati-hatian ekstra. CSP adalah header yang paling kuat, tetapi juga yang paling mudah merusak situs bila disusun sembarangan. Bagi publisher AdSense, aturan resminya jelas: Google hanya mendukung strict CSP berbasis nonce, dan kegagalan mematuhi panduan tersebut dapat mengganggu penayangan iklan. Uji CSP dalam mode Report-Only, pantau laporan pelanggaran selama satu sampai dua minggu, dan jangan menegakkan kebijakan yang Anda salin dari situs lain.

Mulailah dari lima header dasar hari ini, naikkan max-age HSTS secara bertahap, dan perlakukan CSP sebagai proyek terpisah yang membutuhkan inventaris sumber daya dan pengujian yang sabar. Keamanan situs bukanlah pekerjaan sekali selesai, melainkan kebiasaan: periksa header Anda setiap kali tema, plugin, atau hosting berubah, dan situs Anda akan tetap aman tanpa mengorbankan pendapatan iklan.

Sumber resmi yang dirujuk

1. OWASP Secure Headers Project — Response Headers: https://secure-headers-project.owasp.org/response-headers/
2. Google AdSense Help — Integrate the AdSense ad code with a Content Security Policy (CSP): https://support.google.com/adsense/answer/16283098?hl=en
3. MDN Web Docs — HTTP Strict Transport Security: https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
4. MDN Web Docs — X-Frame-Options: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
5. MDN Web Docs — Content-Security-Policy: frame-ancestors: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors
6. RFC 6797 — HTTP Strict Transport Security (HSTS): https://tools.ietf.org/html/rfc6797
7. RFC 7034 — HTTP Header Field X-Frame-Options: https://tools.ietf.org/html/rfc7034
8. Trusted Origin — How to Add Security Headers on WordPress: https://www.trustedorigin.org/fix/security-headers-on-wordpress