30 Agustus 2025Bahasa Indonesia

Panduan komprehensif tentang Content Security Policy (CSP) dan header keamanan frontend lainnya, melindungi aplikasi web dari serangan dan meningkatkan keamanan pengguna secara global.

Header Keamanan Frontend: Menguasai Content Security Policy (CSP)

Dalam lanskap digital saat ini, di mana aplikasi web semakin kompleks dan saling terhubung, perlindungan terhadap ancaman keamanan adalah hal yang terpenting. Meskipun keamanan backend sering mendapat perhatian signifikan, keamanan frontend sama pentingnya. Header keamanan frontend bertindak sebagai garis pertahanan pertama, menyediakan mekanisme untuk menginstruksikan browser tentang bagaimana berperilaku dan melindungi pengguna dari berbagai serangan. Di antara header-header ini, Content Security Policy (CSP) menonjol sebagai alat yang kuat untuk mengurangi berbagai macam risiko.

Apa itu Header Keamanan Frontend?

Header keamanan frontend adalah header respons HTTP yang dikirim server web ke browser. Header ini berisi instruksi tentang bagaimana browser harus menangani konten yang diterimanya. Mereka membantu mencegah serangan umum seperti:

Cross-Site Scripting (XSS): Menyuntikkan skrip berbahaya ke situs web tepercaya.
Clickjacking: Menipu pengguna agar mengklik sesuatu yang berbeda dari yang mereka persepsikan.
Man-in-the-Middle Attacks: Pencegatan komunikasi antara pengguna dan server.

Beberapa header keamanan frontend yang paling penting meliputi:

Content Security Policy (CSP): Mendefinisikan sumber dari mana browser diizinkan untuk memuat sumber daya.
Strict-Transport-Security (HSTS): Memaksa browser untuk menggunakan HTTPS untuk semua komunikasi dengan situs web.
X-Frame-Options: Mencegah situs web disematkan dalam iframe, mengurangi serangan clickjacking.
X-XSS-Protection: Mengaktifkan filter XSS bawaan browser. (Catatan: Sering digantikan oleh CSP tetapi masih dapat memberikan lapisan pertahanan).
Referrer-Policy: Mengontrol jumlah informasi perujuk yang dikirim dengan permintaan.
Feature-Policy (sekarang Permissions-Policy): Memungkinkan pengembang untuk secara selektif mengaktifkan dan menonaktifkan fitur dan API browser.

Menyelami Lebih Dalam Content Security Policy (CSP)

Content Security Policy (CSP) adalah header respons HTTP yang mengontrol sumber daya yang diizinkan untuk dimuat oleh agen pengguna untuk halaman tertentu. Ini pada dasarnya memasukkan sumber konten yang disetujui ke dalam daftar putih, secara signifikan mengurangi risiko serangan XSS. Dengan secara eksplisit mendefinisikan asal dari mana sumber daya seperti skrip, stylesheet, gambar, dan font dapat dimuat, CSP membuatnya jauh lebih sulit bagi penyerang untuk menyuntikkan kode berbahaya ke situs web Anda.

Cara Kerja CSP

CSP bekerja dengan memberikan browser daftar sumber yang disetujui untuk berbagai jenis konten. Ketika browser menemukan sumber daya yang melanggar CSP, ia akan memblokir sumber daya tersebut dan melaporkan pelanggarannya. Mekanisme pemblokiran ini mencegah kode berbahaya dieksekusi, bahkan jika penyerang berhasil menyuntikkannya ke dalam HTML.

Direktif CSP

Direktif CSP adalah komponen inti dari kebijakan CSP. Mereka menentukan sumber yang diizinkan untuk berbagai jenis sumber daya. Beberapa direktif yang paling umum digunakan meliputi:

default-src: Menetapkan sumber default untuk semua jenis sumber daya. Ini adalah direktif cadangan yang berlaku ketika direktif lain yang lebih spesifik tidak ditentukan.
script-src: Menentukan sumber yang diizinkan untuk JavaScript.
style-src: Menentukan sumber yang diizinkan untuk stylesheet CSS.
img-src: Menentukan sumber yang diizinkan untuk gambar.
font-src: Menentukan sumber yang diizinkan untuk font.
media-src: Menentukan sumber yang diizinkan untuk audio dan video.
object-src: Menentukan sumber yang diizinkan untuk plugin seperti Flash. (Umumnya yang terbaik adalah menghindari mengizinkan plugin jika memungkinkan).
frame-src: Menentukan sumber yang diizinkan untuk frame (iframe).
connect-src: Menentukan sumber yang diizinkan untuk permintaan jaringan (AJAX, WebSockets).
base-uri: Membatasi URL yang dapat digunakan dalam elemen <base>.
form-action: Membatasi URL tempat formulir dapat dikirimkan.
frame-ancestors: Menentukan induk yang valid yang dapat menyematkan halaman menggunakan <frame>, <iframe>, <object>, <embed>, atau <applet>. Direktif ini memberikan perlindungan terhadap Clickjacking.
upgrade-insecure-requests: Menginstruksikan agen pengguna untuk memperlakukan semua URL tidak aman situs (dimuat melalui HTTP) seolah-olah telah diganti dengan URL aman (dimuat melalui HTTPS). Direktif ini ditujukan untuk situs web yang sedang dalam proses migrasi dari HTTP ke HTTPS.
report-uri: Menentukan URL ke mana browser harus mengirim laporan tentang pelanggaran CSP. Tidak digunakan lagi dan digantikan oleh `report-to`.
report-to: Menentukan nama grup yang didefinisikan dalam header `Report-To`. Ini memungkinkan kontrol yang lebih terperinci atas pelaporan, termasuk menentukan beberapa titik akhir pelaporan.

Nilai Sumber CSP

Nilai sumber mendefinisikan asal dari mana sumber daya diizinkan untuk dimuat. Beberapa nilai sumber yang umum meliputi:

*: Mengizinkan konten dari sumber mana pun (Hindari penggunaan ini di produksi!).
'self': Mengizinkan konten dari asal yang sama (skema, host, dan port) dengan dokumen yang dilindungi.
'none': Melarang konten dari sumber mana pun.
'unsafe-inline': Mengizinkan penggunaan JavaScript dan CSS inline (Hindari penggunaan ini di produksi!).
'unsafe-eval': Mengizinkan penggunaan evaluasi kode dinamis (misalnya, eval(), Function()) (Hindari penggunaan ini di produksi!).
'strict-dynamic': Menentukan bahwa kepercayaan yang secara eksplisit diberikan pada skrip yang ada di markup, dengan menyertainya dengan nonce atau hash, harus disebarkan ke semua skrip yang dimuat oleh leluhur tersebut.
'unsafe-hashes': Mengizinkan penangan acara inline tertentu. Ini umumnya tidak disarankan karena kompleksitas dan manfaatnya yang terbatas.
data:: Mengizinkan pemuatan sumber daya dari URL data (misalnya, gambar yang disematkan). Gunakan dengan hati-hati.
mediastream:: Mengizinkan URI `mediastream:` untuk digunakan sebagai sumber media.
blob:: Mengizinkan URI `blob:` untuk digunakan sebagai sumber media.
filesystem:: Mengizinkan sumber daya dimuat dari sistem file.
https://example.com: Mengizinkan konten dari domain dan port tertentu.
*.example.com: Mengizinkan konten dari subdomain mana pun dari example.com.
nonce-{random-value}: Mengizinkan skrip atau gaya dengan atribut nonce yang cocok. Ini memerlukan pembuatan nilai nonce acak di sisi server untuk setiap permintaan.
sha256-{hash-value}: Mengizinkan skrip atau gaya dengan hash SHA256, SHA384, atau SHA512 yang cocok.

Mode CSP: Enforce vs. Report-Only

CSP dapat diterapkan dalam dua mode:

Mode Enforce (Penerapan): Dalam mode ini, browser memblokir sumber daya apa pun yang melanggar CSP. Ini adalah mode yang disarankan untuk lingkungan produksi. CSP dikirim menggunakan header `Content-Security-Policy`.
Mode Report-Only (Hanya Laporan): Dalam mode ini, browser melaporkan pelanggaran CSP tetapi tidak memblokir sumber daya. Ini berguna untuk menguji dan mengevaluasi CSP sebelum menerapkannya. CSP dikirim menggunakan header `Content-Security-Policy-Report-Only`.

Menerapkan CSP: Panduan Langkah demi Langkah

Menerapkan CSP bisa tampak menakutkan, tetapi dengan mengikuti pendekatan terstruktur, Anda dapat mengamankan aplikasi web Anda secara efektif.

1. Mulai dengan Kebijakan Report-Only

Mulailah dengan menerapkan CSP dalam mode report-only. Ini memungkinkan Anda untuk memantau pelanggaran tanpa mengganggu fungsionalitas situs web Anda. Konfigurasikan direktif report-uri atau report-to untuk mengirim laporan pelanggaran ke titik akhir yang ditunjuk.

Contoh header (Report-Only): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. Analisis Laporan Pelanggaran

Analisis laporan pelanggaran dengan cermat untuk mengidentifikasi sumber daya mana yang diblokir dan mengapa. Ini akan membantu Anda memahami ketergantungan sumber daya situs web Anda dan mengidentifikasi potensi kerentanan keamanan.

Laporan pelanggaran biasanya dikirim sebagai muatan JSON ke titik akhir report-uri atau report-to yang dikonfigurasi. Laporan ini berisi informasi tentang pelanggaran, seperti URI yang diblokir, direktif yang dilanggar, dan URI dokumen.

3. Perbaiki Kebijakan CSP

Berdasarkan laporan pelanggaran, perbaiki kebijakan CSP Anda untuk mengizinkan sumber daya yang sah sambil tetap mempertahankan postur keamanan yang kuat. Tambahkan nilai sumber spesifik untuk sumber daya yang diblokir. Pertimbangkan untuk menggunakan nonce atau hash untuk skrip dan gaya inline untuk menghindari penggunaan 'unsafe-inline'.

4. Transisi ke Mode Enforce

Setelah Anda yakin bahwa kebijakan CSP Anda tidak memblokir sumber daya yang sah, beralihlah ke mode enforce (penerapan). Ini akan memblokir pelanggaran yang tersisa dan memberikan lapisan keamanan yang kuat terhadap serangan XSS.

Contoh header (Enforce): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. Pantau dan Pelihara Kebijakan CSP

CSP bukanlah solusi sekali pasang dan lupakan. Penting untuk terus memantau kebijakan CSP Anda dan memperbaruinya seiring perkembangan situs web Anda dan munculnya ancaman keamanan baru. Tinjau laporan pelanggaran secara teratur dan sesuaikan kebijakan seperlunya.

Contoh Praktis CSP

Mari kita lihat beberapa contoh praktis CSP untuk skenario yang berbeda:

Contoh 1: CSP Dasar untuk Situs Web Sederhana

CSP ini mengizinkan konten dari asal yang sama dan mengizinkan gambar dari sumber mana pun.

Content-Security-Policy: default-src 'self'; img-src *

Contoh 2: CSP dengan Sumber Skrip dan Gaya Tertentu

CSP ini mengizinkan skrip dari asal yang sama dan dari CDN tertentu, serta gaya dari asal yang sama dan gaya inline.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

Contoh 3: CSP dengan Nonce untuk Skrip Inline

CSP ini memerlukan nonce unik untuk setiap skrip inline.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

Penting: Nilai nonce harus dibuat secara dinamis di server untuk setiap permintaan. Ini mencegah penyerang menggunakan kembali nonce tersebut.

Contoh 4: CSP Membatasi Frame Ancestors untuk Mencegah Clickjacking

CSP ini mencegah halaman disematkan dalam iframe di domain mana pun kecuali `https://example.com`.

Content-Security-Policy: frame-ancestors 'self' https://example.com

Contoh 5: CSP yang lebih ketat menggunakan 'strict-dynamic' dan fallback ke 'self'

CSP ini memanfaatkan `strict-dynamic` untuk browser modern sambil tetap mendukung browser lama yang tidak mendukungnya. Ini juga menyertakan `report-uri` untuk memantau pelanggaran.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Ingatlah untuk mengganti `{random-nonce}` dengan nilai nonce yang dibuat secara dinamis di sisi server.

CSP dan Aplikasi Halaman Tunggal (SPA)

Menerapkan CSP di SPA bisa menjadi tantangan karena sifat dinamis dari aplikasi ini. SPA sering kali sangat bergantung pada JavaScript untuk menghasilkan dan memanipulasi DOM, yang dapat menyebabkan pelanggaran CSP jika tidak ditangani dengan hati-hati.

Berikut beberapa tips untuk menerapkan CSP di SPA:

Hindari 'unsafe-inline' dan 'unsafe-eval': Direktif ini harus dihindari sebisa mungkin di SPA. Mereka secara signifikan melemahkan keamanan aplikasi Anda.
Gunakan Nonce atau Hash: Gunakan nonce atau hash untuk skrip dan gaya inline. Ini adalah pendekatan yang disarankan untuk SPA.
Pertimbangkan Trusted Types: Trusted Types adalah API browser yang membantu mencegah kerentanan XSS berbasis DOM. Ini dapat digunakan bersama dengan CSP untuk lebih meningkatkan keamanan.
Gunakan kerangka kerja yang kompatibel dengan CSP: Beberapa kerangka kerja frontend (seperti React dengan konfigurasi tertentu, Angular, dan Vue.js) menyediakan fitur untuk membantu Anda menerapkan CSP dengan lebih mudah.

Header Keamanan Frontend Penting Lainnya

Meskipun CSP adalah landasan keamanan frontend, header lain memainkan peran penting dalam menyediakan strategi pertahanan yang komprehensif:

Strict-Transport-Security (HSTS)

Header Strict-Transport-Security (HSTS) menginstruksikan browser untuk selalu menggunakan HTTPS untuk terhubung ke situs web. Ini mencegah serangan man-in-the-middle yang mencoba menurunkan koneksi ke HTTP.

Contoh header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age: Menentukan durasi (dalam detik) di mana browser harus ingat untuk hanya mengakses situs melalui HTTPS. Nilai 31536000 detik (1 tahun) direkomendasikan untuk lingkungan produksi.
includeSubDomains: Menunjukkan bahwa kebijakan HSTS berlaku untuk semua subdomain dari domain tersebut.
preload: Memungkinkan domain untuk dimasukkan dalam daftar domain yang diaktifkan HSTS yang dimuat sebelumnya ke dalam browser. Ini memerlukan pengiriman domain Anda ke daftar pramuat HSTS yang dikelola oleh Google.

X-Frame-Options

Header X-Frame-Options mencegah serangan clickjacking dengan mengontrol apakah situs web dapat disematkan dalam iframe.

Contoh header: X-Frame-Options: DENY

Nilai yang mungkin:

DENY: Mencegah halaman ditampilkan dalam iframe, terlepas dari asalnya.
SAMEORIGIN: Mengizinkan halaman ditampilkan dalam iframe hanya jika asal iframe cocok dengan asal halaman.
ALLOW-FROM uri: Mengizinkan halaman ditampilkan dalam iframe hanya jika asal iframe cocok dengan URI yang ditentukan. Catatan: Opsi ini tidak digunakan lagi dan mungkin tidak didukung oleh semua browser.

Catatan: Direktif frame-ancestors di CSP menyediakan cara yang lebih fleksibel dan kuat untuk mengontrol framing dan umumnya lebih disukai daripada X-Frame-Options.

X-XSS-Protection

Header X-XSS-Protection mengaktifkan filter XSS bawaan browser. Meskipun CSP adalah solusi yang lebih kuat untuk mencegah serangan XSS, header ini dapat memberikan lapisan pertahanan tambahan, terutama untuk browser lama yang mungkin tidak sepenuhnya mendukung CSP.

Contoh header: X-XSS-Protection: 1; mode=block

1: Mengaktifkan filter XSS.
0: Menonaktifkan filter XSS.
mode=block: Menginstruksikan browser untuk memblokir halaman jika serangan XSS terdeteksi.
report=uri: Menentukan URL ke mana browser harus mengirim laporan jika serangan XSS terdeteksi.

Referrer-Policy

Header Referrer-Policy mengontrol jumlah informasi perujuk yang dikirim dengan permintaan. Informasi perujuk dapat digunakan untuk melacak pengguna di seluruh situs web, sehingga mengontrolnya dapat meningkatkan privasi pengguna.

Contoh header: Referrer-Policy: strict-origin-when-cross-origin

Beberapa nilai umum:

no-referrer: Jangan pernah mengirim header Referer.
no-referrer-when-downgrade: Jangan mengirim header Referer ke asal tanpa TLS (HTTPS).
origin: Hanya kirim asal (skema, host, dan port) di header Referer.
origin-when-cross-origin: Kirim asal untuk permintaan lintas-asal dan URL lengkap untuk permintaan asal-yang-sama.
same-origin: Kirim header Referer untuk permintaan asal-yang-sama, tetapi tidak untuk permintaan lintas-asal.
strict-origin: Hanya kirim asal ketika tingkat keamanan protokol tetap sama (HTTPS ke HTTPS), tetapi jangan kirim header ke tujuan yang kurang aman (HTTPS ke HTTP).
strict-origin-when-cross-origin: Kirim asal saat melakukan permintaan asal-yang-sama. Untuk permintaan lintas-asal, kirim asal hanya ketika tingkat keamanan protokol tetap sama (HTTPS ke HTTPS), tetapi jangan kirim header ke tujuan yang kurang aman (HTTPS ke HTTP).
unsafe-url: Kirim URL lengkap di header Referer, terlepas dari asalnya. Gunakan dengan sangat hati-hati, karena ini dapat mengekspos informasi sensitif.

Permissions-Policy (sebelumnya Feature-Policy)

Header Permissions-Policy (sebelumnya dikenal sebagai Feature-Policy) memungkinkan pengembang untuk secara selektif mengaktifkan dan menonaktifkan fitur dan API browser. Ini dapat membantu mengurangi permukaan serangan aplikasi Anda dan meningkatkan privasi pengguna.

Contoh header: Permissions-Policy: geolocation=()

Contoh ini menonaktifkan API geolokasi untuk situs web.

Fitur lain yang dapat dikontrol dengan Permissions-Policy meliputi:

camera
microphone
geolocation
accelerometer
gyroscope
magnetometer
usb
midi
payment
fullscreen

Mengatur Header Keamanan di Berbagai Platform

Metode untuk mengatur header keamanan bervariasi tergantung pada server web atau platform yang Anda gunakan. Berikut adalah beberapa contoh umum:

Apache

Anda dapat mengatur header keamanan di Apache dengan menambahkannya ke file .htaccess atau file konfigurasi server (httpd.conf).

Contoh konfigurasi .htaccess:


<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Anda dapat mengatur header keamanan di Nginx dengan menambahkannya ke blok server di file konfigurasi Nginx (nginx.conf).

Contoh konfigurasi Nginx:


server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

Anda dapat mengatur header keamanan di Node.js menggunakan middleware seperti Helmet.

Contoh menggunakan Helmet:


const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Kustomisasi CSP jika perlu
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

Cloudflare memungkinkan Anda untuk mengatur header keamanan menggunakan Page Rules atau Transform Rules mereka.

Menguji Header Keamanan Anda

Setelah menerapkan header keamanan, penting untuk mengujinya untuk memastikan mereka berfungsi dengan benar. Beberapa alat online dapat membantu Anda menganalisis header keamanan situs web Anda:

SecurityHeaders.com: Alat sederhana dan efektif untuk menganalisis header keamanan.
Mozilla Observatory: Alat komprehensif untuk menguji keamanan situs web, termasuk header keamanan.
WebPageTest.org: Memungkinkan Anda untuk melihat header HTTP di bagan air terjun (waterfall chart).

Kesimpulan

Header keamanan frontend, terutama Content Security Policy (CSP), sangat penting untuk melindungi aplikasi web dari berbagai serangan dan meningkatkan keamanan pengguna. Dengan menerapkan dan memelihara header ini dengan hati-hati, Anda dapat secara signifikan mengurangi risiko XSS, clickjacking, dan kerentanan keamanan lainnya. Ingatlah untuk memulai dengan kebijakan report-only, menganalisis laporan pelanggaran, menyempurnakan kebijakan, dan kemudian beralih ke mode enforce. Pantau dan perbarui header keamanan Anda secara teratur untuk menjaga keamanan situs web Anda seiring perkembangannya dan munculnya ancaman baru.

Dengan mengadopsi pendekatan proaktif terhadap keamanan frontend, Anda dapat membangun aplikasi web yang lebih aman dan tepercaya yang melindungi pengguna dan bisnis Anda.