Panduan HTTP Security Headers: Cara Cek Keamanan dan Perbaikan

01-05-2026

Jika kamu sedang melakukan security headers check menggunakan free service dari SecurityHeaders.com, kesalahan terbesar saat ingin menerapkan HTTP Security Header adalah mengaktifkan semua header sekaligus, pasti ada saja error saat semuanya diaktifkan secara bersamaan.

Maka dari itu pendekatan yang lebih baik adalah meninjau setiap HTTP Security Header, menerapkan quick wins terlebih dahulu lalu dilanjutkan ke trial perubahan yang berisiko, memperbaiki header dalam urutan yang tepat akan memudahkan dalam penerapan HTTP Security Header.

Sebagai contoh kita akan menggunakan result dari SecurityHeaders.com dari website ini.

Site: https://potato.id/
IP Address: 172.67.219.34
Report Time: 22 Apr 2026 16:50:39 UTC
Headers:
- Referrer-Policy
- Content-Security-Policy
- X-Frame-Options
- Strict-Transport-Security
- X-Content-Type-Options
- Permissions-Policy

Warning: Grade capped at A, please see warnings below.

Bagian menarik di sini bukan cuma nilainya yang sudah mendapatkan A Grade. Yang penting malah detail warning-nya. Sebuah website bisa terlihat sudah “bagus” atau mendapat Grade A di SecurityHeaders.com, tetapi tetap punya beberapa pengaturan yang sebaiknya diperketat lebih dulu.

Point apa yang digunakan sebagai standar di SecurityHeaders.com

SecurityHeaders.com melakukan penilaian keamanan website dengan mengecek presensi dan konfigurasi HTTP response header untuk menerapkan praktik keamanan yang kuat. SecurityHeaders.com meninjau sekumpulan header penting untuk menilai seberapa baik sebuah website melindungi penggunanya dari kerentanan umum seperti cross-site scripting (XSS), clickjacking dan serangan injeksi data. Header yang dicek mencakup perlindungan penting seperti Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options dan header lain yang menjadi fondasi keamanan web modern.

Dari konfigurasi saat ini, potato.id sudah berhasil menerapkan beberapa security header penting:

Redirect HTTP ke HTTPS, sehingga komunikasi terenkripsi
Menggunakan X-Frame-Options: DENY untuk mencegah serangan clickjacking
Menerapkan X-Content-Type-Options: nosniff untuk memblokir MIME-type sniffing
Mengatur Referrer-Policy: no-referrer untuk melindungi data referrer sensitif
Mengaktifkan Strict-Transport-Security (HSTS) untuk koneksi yang aman
Menerapkan Content-Security-Policy (CSP) untuk mengontrol pemuatan resource javascript pihak ketiga

Dari hasil ini sudah terlihat bagus namun peninjauan security header tidak seharusnya berhenti di situ, karena biasanya ada dua hal yang paling penting setelah basic http security header sudah ada, yaitu:

Sebuah header bisa saja masih belum ada sama sekali, meskipun tidak selalu disorot jelas di report dasar, misalnya Permissions-Policy
Sebuah header bisa saja sudah ada tetapi terlalu permisif, terutama pada Content-Security-Policy, yang memang perlu tuning dengan hati-hati agar efektif

Itulah kenapa perbaikan berikutnya biasanya soal kualitas, bukan sekadar keberadaan header.

HTTP Security Header Mana yang Sebaiknya Diperbaiki Lebih Dulu?

Berikut adalah saran untuk meningkatkan HTTP security headers dengan cepat tanpa membuat website error, pendekatan terbaik adalah memprioritaskan perbaikan berdasarkan seberapa mudah implementasinya dan seberapa rendah risikonya.

1. Aktifkan Header Berikut yang Tidak Mengganggu Websitemu (Quick Wins)

Berikut adalah HTTP Security Header yang aman jika diterapkan secara langsung, jika belum ada bisa segera ditambahkan di konfigurasi webservermu

X-Content-Type-Options: nosniff untuk mencegah MIME-type sniffing
X-Frame-Options: DENY untuk memblokir clickjacking
Referrer-Policy: no-referrer untuk membatasi informasi referer
Redirect HTTP ke HTTPS secara default dan aman

List tersebut dianggap sebagai baseline security headers dan biasanya jadi pemeriksaan pertama oleh tools seperti SecurityHeaders.com.

2. Tambahkan Permissions-Policy (Simple)

Jika Header sebelumnya sudah aman kamu bisa menerapkan Permissions-Policy

Kenapa Header ini masih termasuk mudah?, karena:

Tidak memengaruhi layout atau rendering
Hanya membatasi fitur browser
Aman jika mengaktifkan deny-all secara default

Contoh baseline:

Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=()

Dengan Header tersebut kamu akan menonaktifkan akses ke API browser yang sensitif kecuali memang diizinkan secara eksplisit, sehingga mengurangi exposure yang tidak perlu dengan effort yang minim.

3. Aktifkan dan pastikan HTTPS + HSTS Dasar (Low Complexity)

Jika websitemu sudah melakukan redirect ke HTTPS secara default, langkah berikutnya adalah mengaktifkan Header Strict-Transport-Security (HSTS)

Basic version:

Strict-Transport-Security: max-age=15552000

Pada tahap ini, buat sesederhana mungkin:

Jangan pikirkan preload HSTS
Jangan paksa subdomain jika kamu belum yakin semua service di subdomain lain sudah redirect HTTPS dan terkonfigurasi certificate SSL/TLS-nya

Langkah ini memperkuat keamanan di layer transport tanpa menambah banyak risiko.

4. Perluas HSTS (Menengah, Perlu Monitoring dan Uji Coba)

Setelah HTTPS stabil di semua subdomain, kamu bisa menaikkan HSTS dengan mengaktifkan di setiap subdomain dan menaikan value max-age

Strict Version:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Dengan menerapkan Header tersebut kamu akan meningkatkan max-age yang tinggi, tapi butuh memastikan untuk:

Semua subdomain mendukung HTTPS
Sertifikat TLS/SSL dikelola dengan konsisten

Masih relatif mudah, tetapi jika kurang pas atau error bisa berdampak luas dan cukup lama untuk safe fail.

5. Perketat Content-Security-Policy (Tersulit, Dampak Terbesar)

Header ini cukup kompleks dan membingungkan, perlu trial and error untuk mengaktifkan Header ini Meskipun sudah mengaktifkan CSP, konfigurasi CSP bisa saja masih terlalu luas sehingga nilainya diturunkan, tools seperti SecurityHeaders.com akan menandai policy berikut jika diaktifkan:

'unsafe-inline'
'unsafe-eval'
Wildcard seperti *

Hal-hal tersebut akan melemahkan perlindungan terhadap XSS dan abuse script pihak ketiga.

Untuk meningkatkan CSP membutuhkan:

Audit semua script dan resource
Mengganti directive yang tidak aman dengan nonce atau hash
Testing menyeluruh sebelum enforcement penuh

Inilah alasan kenapa CSP diletakkan paling akhir, karena memberikan peningkatan keamanan paling besar tapi juga punya risiko paling tinggi untuk merusak fungsi dan tampilan website.

Urutan Perbaikan Praktis dari yang Termudah sampai yang Tersulit

Berikut urutan optimasi yang direkomendasikan dari yang paling mudah sampai yang paling sulit

Pertahankan dan verifikasi header baseline (nosniff, DENY, Referrer-Policy, redirect HTTPS)
Tambahkan atau rapikan Permissions-Policy
Aktifkan dan validasi HSTS
Perluas HSTS setelah HTTPS benar-benar stabil
Perketat Content-Security-Policy (CSP) secara bertahap dengan audit kebutuhan website

Pendekatan ini menyeimbangkan quick wins dan hardening jangka panjang tanpa merusak website.

Apa yang Sebaiknya Diperbaiki Selanjutnya (Berdasarkan Hasil Website Ini)

Berdasarkan konfigurasi security header website ini saat ini, sebagian besar header inti sudah diterapkan. Artinya, fokus berikutnya sebaiknya bergeser dari sekadar menambahkan header menjadi meningkatkan kualitasnya, seperti yang biasanya disorot oleh tools seperti SecurityHeaders.com.

Urutan prioritas:

Permissions-Policy
Perlu menambahkan Permissions-Policy baru sesuai kebutuhan website.
Content-Security-Policy
Ini kemungkinan jadi titik paling lemah. Meski sudah ada, konfigurasi yang dipakai bisa saja masih terlalu permisif, jadi fokusnya adalah menghapus directive yang tidak aman, membatasi source dan memperketat kontrol secara bertahap.
Strict-Transport-Security (Extended)
HSTS sudah aktif. Sekarang saatnya meningkatkannya lebih jauh seperti preload dan max-age yang lebih tinggi.

Poin penting:

Website ini sudah memiliki security headers yang esensial, jadi prioritasnya bukan lagi mengejar skor lebih tinggi, tetapi membuat header yang ada menjadi lebih ketat dan lebih efektif. Peningkatan terbesar kemungkinan datang dari perbaikan Content-Security-Policy (CSP), karena di situlah kelemahan paling sering tersisa di dunia nyata meskipun sebuah website terlihat sudah “aman” di tools seperti SecurityHeaders.com.

Contoh Nginx untuk Baseline Security Header yang Lebih Baik

add_header X-Frame-Options "DENY" always;           # Quick Win
add_header X-Content-Type-Options "nosniff" always; # Quick Win
add_header Referrer-Policy "no-referrer" always;    # Quick Win
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always; # Quick Win
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # Moderate, needs short trial
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';" always; # Complex, needs auditing

Konfigurasi ini mencakup HTTP response header inti yang diperlukan untuk melindungi dari ancaman umum seperti:

Clickjacking
MIME-type sniffing
Kebocoran data melalui referrer
Akses fitur browser tanpa izin
Koneksi HTTP yang tidak aman

Konfigurasi ini juga membangun Content Security Policy (CSP) minimal yang tetap aman untuk mengontrol cara resource dimuat. Tetapi Content-Security-Policy (CSP) tidak boleh dianggap sebagai solusi yang cocok untuk semua kasus, karena bisa merusak aplikasi web berbasis JavaScript. Itulah kenapa CSP harus diperlakukan dengan hati-hati dan diaudit penuh terhadap JavaScript serta layanan pihak ketiga yang digunakan aplikasi kamu.

Kalau kamu juga sedang mencoba menaikkan skor test HTTPS, lihat Cara Meningkatkan Skor Qualys SSL Server Test dan Mendapatkan A+ di SSL Labs.

FAQ

Security header apa yang pertama kali sebaiknya diperbaiki di sebuah website?

Kalau header dasarnya sudah ada, Permissions-Policy sering jadi peningkatan pertama yang paling aman karena mudah ditambahkan dan risikonya rendah. Kalau website kamu masih punya CSP yang lemah, maka Content-Security-Policy biasanya jadi perbaikan lanjutan yang paling penting.

Kenapa SecurityHeaders.com menampilkan nilai bagus tetapi tetap memberi warning?

Karena sebuah website bisa saja sudah memiliki semua header yang diwajibkan, tetapi konfigurasi tiap header masih terlalu longgar. Warning dari SecurityHeaders.com membantu menunjukkan celah keamanan yang nyata, bukan cuma sekadar keberadaan header.

Apakah CSP lebih penting daripada X-Frame-Options?

Dalam keamanan web modern, ya. Walaupun X-Frame-Options melindungi dari clickjacking, CSP memberi kontrol yang lebih luas terhadap script, resource dan trust boundary.

Apakah security headers membuat website jadi sepenuhnya aman?

Tidak. Security headers memang mengurangi risiko di sisi browser, tetapi tidak memperbaiki kode yang vulnerable, autentikasi yang lemah, plugin yang tidak aman atau patching server yang buruk.

Final Thoughts

HTTP Security header bukan soal ngejar skor bagus di SecurityHeaders.com. Namun lebih ke bagaimana kita membuat perlindungan yang masuk akal dan tidak membuat aplikasi bermasalah atau terdampak.

Mulai dari yang mudah terlebih dulu. Setelah itu baru pelan-pelan diperketat sambil dites. Security is a process, there is no silver bullet

HTTP Security header hanyalah salah satu lapisan dalam defense-in-depth. Header ini melakukan pengamanan pada level browser dan tidak dapat menggantikan secure coding, validasi input, manajemen akses atau patching sistem.