SRI, dijelaskan: sidik jari digital untuk aset website-mu

Dalam satu kalimat

Subresource Integrity (SRI) adalah fitur keamanan yang memungkinkan browser memverifikasi bahwa file yang mereka ambil dari sumber eksternal, seperti CDN, belum diutak-atik secara diam-diam.

Masalah yang diselesaikan

Bayangin gini: kamu lagi bikin web app baru yang keren. Biar kenceng, kamu pakai Content Delivery Network (CDN) untuk menyajikan library umum seperti React, Vue, atau bahkan sekadar font keren. Ini praktik standar. Pengguna kamu dapat pengalaman yang lebih cepat karena file tersebut kemungkinan sudah di-cache di browser mereka dari situs lain yang pernah dikunjungi, atau disajikan dari server yang secara fisik lebih dekat dengan mereka. Sama-sama untung, kan?

Kebanyakan sih iya. Tapi, kamu baru saja memasukkan elemen kepercayaan yang masif. Kamu percaya bahwa penyedia CDN akan selalu menyajikan file yang persis seperti yang kamu maksud. Gimana kalau CDN itu kena hack? Seorang penyerang bisa mengganti react.min.js yang ramah dan berguna dengan versi berbahaya: react.min.js-plus-a-crypto-miner-and-password-stealer.

Tiba-tiba, kode berbahaya ini berjalan di website kamu, dengan kepercayaan penuh dari browser pengguna kamu. Kode itu bisa menyedot kredensial login, merusak tampilan halamanmu, atau mendaftarkan pengunjungmu ke dalam botnet. Ini adalah serangan supply-chain klasik, dan ini mengerikan karena kamu tidak melakukan kesalahan apa pun di servermu sendiri. Kamu hanya salah percaya pihak di waktu yang salah.

Sebelum ada SRI, tidak ada mekanisme browser bawaan untuk bertahan dari serangan ini. Para developer pakai cara akal-akalan, tapi ribet. SRI dibuat oleh W3C untuk menyelesaikan masalah spesifik ini secara langsung. SRI menyediakan cara yang simpel dan terstandarisasi untuk bilang ke browser, "Woy, ambil script ini, tapi sebelum kamu jalankan, pastikan benar-benar ini file yang aku harapkan. Kalau beda satu byte pun, buang jauh-jauh dan kasih tau aku."

Cara kerjanya di balik layar

SRI adalah perkawinan cerdas antara atribut HTML yang simpel dan beberapa prinsip kriptografi yang serius. Mari kita bedah.

Atribut `integrity`

Keajaibannya dimulai dengan atribut baru yang bisa kamu tambahkan ke tag <script> dan <link> kamu. Namanya, pas banget, integrity.

<script
  src="https://code.jquery.com/jquery-3.6.0.min.js"
  integrity="sha384-oBqDVmMz9ATKxIep9tiCxS/Z9fNfEXiDAYTujMAeBAsjFuCZSmKbSSUnQlmh/jp3"
  crossorigin="anonymous"></script>

Atribut ini berisi string dengan dua bagian: prefix algoritma hash (di sini, sha384-) dan cryptographic hash yang di-encode dengan Base64. Inilah "sidik jari digital" dari file yang kamu harapkan diterima.

Hash: Sidik Jari Digital

Fungsi cryptographic hash adalah algoritma matematika yang mengambil input (seperti seluruh konten file JavaScript) dan menghasilkan string karakter pendek dengan ukuran tetap, yang disebut hash. Anggap saja ini seperti checksum versi super.

Hash ini punya beberapa properti penting:

Deterministik: File input yang sama akan selalu menghasilkan hash yang persis sama.
Efek Longsor (Avalanche Effect): Ubah satu karakter saja di file input—tambah spasi, ganti nama variabel—dan hash yang dihasilkan akan benar-benar berbeda dan tidak bisa dikenali.
Satu Arah: Hampir mustahil untuk membalik prosesnya. Kamu tidak bisa mengambil hash dan mencari tahu apa isi file aslinya.

Standar SRI mendukung tiga algoritma hash yang aman: SHA-256, SHA-384, dan SHA-512. Angkanya mengacu pada panjang bit dari hash, dan semakin besar umumnya semakin kuat. SHA-384 adalah pilihan serbaguna yang mantap.

Jadi, saat kamu akan menautkan ke file CDN, kamu harus membuat hash-nya terlebih dahulu. Pada dasarnya, kamu mengambil snapshot dari file pada saat itu dan memberi tahu browser, "Beginilah tampilan jquery-3.6.0.min.js yang asli."

Atribut `crossorigin`

Lihat crossorigin="anonymous" di contoh tadi? Itu bukan cuma hiasan; itu wajib. Agar browser bisa mengambil resource dari origin yang berbeda (misalnya, situsmu my-app.com mengambil script dari code.jquery.com) dan memeriksa isinya untuk pengecekan SRI, browser memerlukan izin melalui Cross-Origin Resource Sharing (CORS).

Mengatur crossorigin="anonymous" memberitahu browser untuk membuat request tanpa mengirim kredensial pengguna seperti cookie atau header otentikasi HTTP. Ini adalah keharusan untuk keamanan dan privasi. Jika kamu lupa atribut ini, browser akan menolak melakukan pengecekan integritas dan langsung memblokir resource agar tidak dimuat, yang akhirnya membuat situsmu rusak.

Menyatukan Semuanya: Daftar Periksa Browser

Ketika browser menemukan tag dengan atribut integrity, ia akan mengikuti protokol ketat ini:

Browser melihat tag <script> dan mencatat atribut src, integrity, dan crossorigin.
Browser mengirim request untuk file di URL src. Berkat crossorigin, ini adalah request CORS.
File diunduh.
Penting, sebelum mengeksekusi apa pun, browser menghitung hash-nya sendiri dari konten file yang diunduh, menggunakan algoritma yang sama yang ditentukan di atribut integrity (misalnya, sha384).
Kemudian, browser membandingkan hash yang baru dihitung dengan hash yang kamu berikan di atribut.
Jika cocok: Hore! File tersebut asli. Browser mengeksekusi script atau menerapkan stylesheet.
Jika tidak cocok: BAHAYA! Browser mengasumsikan file tersebut telah diutak-atik. Browser akan membuang file tersebut sepenuhnya dan tidak mengeksekusinya. Kemudian, ia akan memunculkan error Failed to find a valid digest di konsol developer. Situsmu mungkin terlihat rusak (misalnya, grafik atau font yang hilang), tapi kamu berhasil menghindari peluru.

Kisah nyata

Dashboard Analitik yang Dirusak

Sebuah tim marketing mengandalkan dashboard yang menggunakan library charting pihak ketiga, diambil dari CDN yang tidak terlalu populer, untuk memvisualisasikan data kampanye mereka. Developernya, yang baru saja membaca tentang praktik keamanan terbaik, telah menambahkan hash SRI ke tag <script> library tersebut. Suatu Senin pagi, CDN tersebut sempat disusupi. Seorang penyerang mengganti library charting populer itu dengan script yang hanya menampilkan wajah ASCII art raksasa yang mengejek.

Ketika tim marketing memuat dashboard mereka, grafiknya rusak. Mereka hanya melihat kotak-kotak kosong. Mereka menelepon IT dengan kesal. Developernya memeriksa konsol browser dan melihat error validasi SRI yang sangat indah. Browser telah mendeteksi file yang dimodifikasi, menolak untuk menjalankannya, dan mencegah kerusakan tampilan. Alih-alih insiden keamanan besar dan para petinggi yang panik, yang terjadi hanyalah investigasi 15 menit yang berakhir dengan mengarahkan sementara ke CDN yang berbeda.

Pelajaran: SRI mengubah potensi bencana keamanan menjadi masalah ketersediaan yang bisa ditangani.

Penambang Kripto yang Licik

Sebuah library utilitas JavaScript yang populer dan ringan yang di-hosting di CDN gratis menjadi favorit para developer indie. Seorang penyerang berhasil mendapatkan akses ke CDN dan memodifikasi file library tersebut, menambahkan beberapa baris kode yang di-obfuscate yang menyalakan penambang kripto WebAssembly. Ukuran filenya nyaris tidak berubah, dan fungsi inti library masih bekerja dengan sempurna.

Website yang menggunakan library tersebut tanpa SRI tiba-tiba membuat laptop penggunanya menyalakan kipas dan menguras baterai. Pengguna mengeluh tentang kelambatan, tapi sulit untuk didiagnosis. Situsnya sendiri terlihat baik-baik saja. Namun, situs yang telah menerapkan SRI kebal. Browser mereka memblokir script yang dimodifikasi, dan meskipun fungsi utilitasnya rusak, CPU pengguna mereka aman.

Pelajaran: SRI tidak hanya menangkap kerusakan tampilan yang jelas tetapi juga serangan parasit yang halus yang dapat merusak reputasi situsmu.

Pembaruan Font yang Terlupakan

Seorang desainer bersikeras menggunakan versi font tertentu dari penyedia font pihak ketiga, yang disajikan melalui CDN mereka. Developernya dengan patuh menyalin tag <link>, lengkap dengan hash SRI-nya. Situsnya diluncurkan dan tampak hebat. Enam bulan kemudian, penyedia font memperbarui file font untuk menambahkan simbol mata uang baru dan memperbaiki kerning. Itu adalah pembaruan yang sah dan bermanfaat.

Tiba-tiba, teks situs kembali menjadi Arial default yang jelek. Developernya bingung sampai mereka memeriksa konsol dan melihat error SRI. Browser dengan benar memblokir file font baru yang dimodifikasi karena hash-nya tidak lagi cocok dengan yang lama di HTML. "Serangan" itu hanyalah pembaruan yang tidak berbahaya, tetapi SRI melakukan tugasnya. Perbaikannya sederhana: buat hash baru untuk font yang diperbarui dan deploy perubahannya.

Pelajaran: SRI menerapkan versioning yang ketat. Ini melindungimu dari perubahan jahat dan pembaruan upstream yang tidak terduga, memaksamu untuk sengaja dan sadar tentang aset yang kamu gunakan.

Kesalahan dan jebakan umum

Lupa crossorigin="anonymous". Ini adalah kesalahan nomor #1. Tanpanya, browser tidak memiliki izin CORS untuk memeriksa resource, jadi demi keamanan, browser langsung memblokirnya. Tidak ada pengecekan integritas yang terjadi. Script atau style-mu gagal dimuat begitu saja.
Menghitung hash dari hal yang salah. Kamu harus menghitung hash dari konten file yang persis diterima oleh browser. Jangan menghitung hash dari versi script lokal yang belum dikompres jika kamu menautkan ke versi minified di CDN. Jangan menghitung hash dari string URL itu sendiri. Kamu perlu hash dari body file.
Menggunakan algoritma hash yang lemah. MD5 dan SHA-1 memiliki kerentanan yang diketahui dan tidak boleh digunakan untuk tujuan keamanan. Spesifikasi mengharuskan browser untuk mendukung setidaknya SHA-256, SHA-384, dan SHA-512. Tetap gunakan yang itu.
Tidak memperbarui hash setelah pembaruan yang sah. SRI adalah fitur, bukan bug. Jika file yang kamu tautkan diperbarui karena alasan apa pun, kamu wajib membuat hash integritas baru dan memperbarui atribut integrity di HTML-mu. Kegagalan melakukannya akan mengakibatkan resource diblokir.
Berpikir SRI melindungi server-mu sendiri. SRI dirancang untuk memvalidasi resource pihak ketiga. Jika penyerang telah menyusupi server-mu dan dapat mengubah file HTML-mu, mereka bisa saja mengubah hash SRI agar cocok dengan script berbahaya mereka. SRI tidak memberikan manfaat untuk resource dari origin yang sama.

Kenapa ini harus kamu perhatikan

Kamu harus memikirkan SRI setiap kali kamu menulis <script src="..."> atau <link rel="stylesheet" href="..."> yang mengarah ke domain yang tidak kamu kontrol.

Ini adalah bagian mendasar dari keamanan web modern. Di dunia yang dibangun di atas NPM, CDN, dan jaring-jaring dependensi pihak ketiga yang kompleks, supply chain-mu adalah permukaan serangan yang masif. SRI adalah salah satu alat paling simpel dan efektif untuk memperkuat permukaan tersebut. Ini adalah garis pertahanan pertamamu melawan CDN yang disusupi. Dipasangkan dengan Content Security Policy (CSP), SRI memberikan perlindungan berlapis yang kuat.

Menambahkan SRI hanya butuh beberapa detik ekstra saat kamu menambahkan resource, tetapi bisa menyelamatkanmu dari banyak masalah di kemudian hari. SRI mengubah exploit yang senyap dan berbahaya menjadi kegagalan yang berisik dan aman.

Pelajari lebih dalam

MDN Web Docs: Subresource Integrity - Referensi definitif untuk developer.
W3C Recommendation: Subresource Integrity - Spesifikasi teknis resmi. Kalau kamu mau menyelam paling dalam, ini tempatnya.
Can I use... Subresource Integrity - Tabel kompatibilitas browser terkini untuk SRI.
Wikipedia: Cryptographic hash function - Untuk pemahaman yang lebih baik tentang keajaiban "sidik jari" di balik SRI.
Scott Helme: Subresource Integrity - Artikel blog keren dari seorang ahli keamanan tentang apa, mengapa, dan bagaimana.