Cara Memasang Security Headers seperti CSP dan HSTS

Pernah mengecek websitemu di alat pemindai header dan mendapat nilai merah, padahal sertifikat SSL sudah terpasang? Itu wajar. SSL mengenkripsi koneksi, tapi tidak memberi tahu browser apa yang boleh dan tidak boleh dilakukan halamanmu. Tugas itu dipegang security headers, yaitu baris tambahan di respons HTTP yang dibaca browser.

Sebagian besar header cukup ditambahkan satu baris di konfigurasi Nginx atau Apache. Yang butuh kesabaran hanya Content-Security-Policy (CSP), karena header ini bisa memblokir skrip milikmu sendiri bila disusun terburu-buru. Panduan ini mengurutkan pemasangannya dari yang paling aman sampai yang paling perlu diuji.

Sebelum mulai: cek kondisi sekarang

Lihat header yang sudah dikirim server dengan perintah:

curl -sI https://domainmu.com

Catat header apa yang sudah ada. Panel hosting, CDN, atau plugin CMS kadang sudah menambahkan sebagian, dan header ganda dengan nilai berbeda bisa membingungkan browser.

Satu catatan untuk Nginx: perintah add_header di blok location membatalkan semua add_header yang diwarisi dari blok server. Kalau kamu menambah header di location, ulangi semua header keamanan di sana, atau taruh di file terpisah lalu include di setiap blok. Tambahkan juga parameter always agar header ikut terkirim pada respons error. Di Apache, pastikan modul mod_headers aktif.

Langkah pemasangan

Langkah 1: HSTS untuk memaksa HTTPS

Strict-Transport-Security memberi tahu browser agar selalu memakai HTTPS untuk domainmu selama waktu tertentu, bahkan bila pengguna mengetik http://. Pasang hanya setelah HTTPS berjalan baik di semua halaman dan subdomain yang akan dicakup.

Mulailah dengan durasi pendek, misalnya satu hari, lalu naikkan bertahap.

add_header Strict-Transport-Security "max-age=86400" always;

Header always set Strict-Transport-Security "max-age=86400"

Setelah yakin, naikkan ke satu tahun (max-age=31536000) dan tambahkan includeSubDomains bila semua subdomain sudah HTTPS. Opsi preload dan pendaftaran ke daftar preload browser bersifat sulit ditarik kembali, jadi pertimbangkan matang-matang. Pilihan sertifikatnya dibahas di jenis sertifikat SSL.

Langkah 2: X-Content-Type-Options

Header ini mencegah browser "menebak" jenis file. Tanpa header ini, file yang diunggah pengguna bisa saja diperlakukan sebagai skrip.

add_header X-Content-Type-Options "nosniff" always;

Header ini jarang menimbulkan masalah, asalkan server mengirim Content-Type yang benar untuk file JavaScript dan CSS. Pasang di semua website.

Langkah 3: Referrer-Policy

Mengatur seberapa banyak alamat halaman asal dikirim saat pengunjung mengklik tautan ke situs lain. Nilai strict-origin-when-cross-origin mengirim alamat lengkap untuk tautan internal, tapi hanya domain untuk tautan keluar, dan tidak mengirim apa pun dari HTTPS ke HTTP.

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Ini penting bila URL-mu memuat informasi seperti token reset password atau nomor pesanan.

Langkah 4: perlindungan dari framing (clickjacking)

Clickjacking terjadi ketika halamanmu dimuat diam-diam di dalam frame situs lain, lalu pengguna ditipu untuk mengklik tombol. Ada dua cara mencegahnya: header lama X-Frame-Options dan direktif CSP frame-ancestors yang lebih baru. Pasang keduanya untuk browser lama dan baru.

add_header X-Frame-Options "SAMEORIGIN" always;

Pakai DENY bila halamanmu tidak pernah perlu dimuat dalam frame, termasuk oleh situsmu sendiri.

Langkah 5: Permissions-Policy

Membatasi fitur browser yang boleh dipakai halaman, seperti kamera, mikrofon, dan lokasi. Kalau websitemu tidak memakainya, matikan.

add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Bila ada fitur yang memang dipakai, misalnya peta toko yang meminta lokasi, izinkan untuk situsmu sendiri dengan geolocation=(self).

Langkah 6: CSP, mulai dari mode Report-Only

CSP menentukan dari mana skrip, gaya, gambar, font, dan frame boleh dimuat. Ini pertahanan kuat terhadap XSS, tapi juga header yang paling sering membuat website rusak.

Kirim dulu dalam mode laporan, yang tidak memblokir apa pun, hanya mencatat pelanggaran di konsol browser:

add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'" always;

Buka halaman-halaman penting, termasuk checkout, formulir, dan halaman dengan video atau peta. Catat sumber yang diblokir di konsol, misalnya domain analitik, CDN font, atau widget chat. Tambahkan sumber yang memang kamu pakai ke direktif yang sesuai. Setelah beberapa hari tanpa laporan yang tidak terduga, ganti nama header menjadi Content-Security-Policy.

Hindari 'unsafe-inline' dan 'unsafe-eval' di script-src bila memungkinkan, karena keduanya melemahkan perlindungan XSS. Untuk skrip inline yang tidak bisa dipindah, pertimbangkan nonce atau hash.

Bagaimana menguji hasilnya?

Muat ulang konfigurasi (nginx -t && systemctl reload nginx, atau apachectl configtest lalu reload Apache), lalu cek lagi dengan curl -sI. Untuk penilaian yang lebih lengkap, gunakan alat pemindai header publik seperti securityheaders.com atau Mozilla HTTP Observatory. Keduanya memberi nilai dan saran per header.

Uji juga dari sisi pengguna: login, checkout, unggah file, dan fitur pihak ketiga. Header keamanan yang membuat pelanggan gagal membayar bukan kemenangan.

Ringkasan header

Header keamanan melengkapi, bukan menggantikan, perlindungan lain. WAF menyaring permintaan berbahaya sebelum sampai ke aplikasi, seperti dibahas di apa itu WAF, sedangkan pengamanan server Nginx yang lebih luas ada di hardening Nginx untuk server produksi.

Checklist sebelum selesai:

• HTTPS berjalan di semua halaman sebelum HSTS dipasang.
• nosniff, Referrer-Policy, X-Frame-Options, dan Permissions-Policy aktif.
• CSP sudah diuji dalam mode Report-Only di halaman penting.
• Header dicek ulang dengan curl -sI dan alat pemindai.
• Login, checkout, dan formulir diuji setelah perubahan.