Subresource Integrity Mengikat Aset Browser ke Byte yang Disetujui

Sebuah halaman web dapat memuat kode executable dari infrastruktur di luar batas deployment aplikasi. URL <script> dapat menunjuk ke CDN, endpoint distribusi package, atau origin lain dengan proses release terpisah. TLS melindungi koneksi ke endpoint tersebut, tetapi response HTTPS yang valid tetap dapat membawa byte yang berbeda dari versi yang dimaksudkan oleh pembuat halaman.

Subresource Integrity, yang umum disingkat SRI, menambahkan pemeriksaan konten di browser. Dokumen membawa metadata digest kriptografis untuk sebuah resource. Setelah mengambil resource, browser menghitung digest yang berlaku dan membandingkannya dengan metadata sebelum menerima resource untuk penggunaan yang dilindungi.

Kontrol ini sengaja memiliki cakupan sempit. SRI mengikat konten yang diharapkan, bukan identitas atau kualitas operasional layanan hosting.

Nilai integrity mendeskripsikan konten yang diharapkan

Untuk sebuah script, metadata integrity ditempatkan pada atribut integrity:

<script
  src="https://cdn.example.net/app.min.js"
  integrity="sha384-BASE64_DIGEST"
  crossorigin="anonymous"></script>

Entri metadata menggabungkan nama algoritma hash yang didukung dengan digest berformat Base64. SHA-256, SHA-384, dan SHA-512 ditetapkan untuk penggunaan SRI saat ini. Digest harus dihitung dari representasi resource yang persis seperti yang diharapkan browser.

Perbedaan satu byte menghasilkan digest berbeda dengan probabilitas yang sangat tinggi pada fungsi hash kriptografis tersebut. Minification, perubahan komentar source map, konversi line ending, perubahan banner, atau transformasi otomatis oleh CDN dapat membuat metadata tidak valid walaupun program yang dihasilkan tampak memiliki fungsi yang sama.

Sensitivitas tersebut memang merupakan tujuan mekanisme ini. SRI tidak menilai apakah dua program berperilaku serupa. Pemeriksaannya menentukan apakah byte yang diambil cocok dengan konten yang disetujui saat metadata dibuat.

Ketidakcocokan membuat resource yang dilindungi ditolak

Saat metadata integrity berlaku, browser tidak menganggap response HTTP yang sukses sebagai syarat yang cukup. Browser mengevaluasi response terhadap metadata integrity. Jika tidak ada digest yang berlaku dan cocok, resource yang dilindungi ditolak, bukan dijalankan atau diterapkan seolah pemeriksaan berhasil.

Hal ini mengubah salah satu failure mode untuk JavaScript yang di-host secara eksternal. Tanpa content pin, kendali atas URL resource dapat cukup untuk mengganti kode yang dikirim ke pengunjung. Dengan metadata SRI yang benar, byte pengganti juga harus memenuhi digest yang tercantum di dokumen.

SRI tidak membuat resource hasil kompromi menjadi aman. Penyerang yang juga dapat mengubah HTML atau response header yang menyediakan metadata integrity mungkin dapat mengganti resource sekaligus digest yang diharapkan. Pemisahan trust memberi nilai saat dokumen dan resource yang dipin tidak berbagi jalur modifikasi tak terkendali yang sama.

Pemisahan yang sama berlaku pada credential deployment. Jika satu credential dapat memublikasikan HTML aplikasi dan aset eksternal, digest tidak menciptakan approval boundary independen terhadap kompromi credential tersebut.

Pemeriksaan cross-origin berinteraksi dengan CORS

SRI cross-origin terkait dengan pemrosesan CORS. Browser memerlukan response yang mengaktifkan CORS untuk resource cross-origin yang kontennya diperiksa integritasnya. Markup umumnya memakai crossorigin="anonymous", sementara server resource mengirim header Access-Control-Allow-Origin yang sesuai.

Persyaratan ini penting secara operasional. Menambahkan nilai integrity tanpa konfigurasi CORS CDN yang kompatibel dapat mengubah rollout keamanan menjadi kegagalan pemuatan di production.

Atribut crossorigin bukan pemeriksaan integritas itu sendiri. Atribut tersebut memilih perilaku CORS untuk request. Perbandingan digest tetap menjadi mekanisme yang mengikat representasi yang diambil dengan metadata.

Jalur deployment same-origin dan cross-origin karena itu perlu diuji sebagaimana browser akan memintanya, termasuk redirect, response header, caching layer, serta transformasi yang dapat mengubah byte akhir.

Beberapa digest dapat mendukung transisi terkontrol

Atribut integrity dapat memuat beberapa entri metadata yang dipisahkan whitespace. Bentuk ini dapat dipakai ketika deployment secara sengaja mengizinkan lebih dari satu representasi yang disetujui selama masa transisi.

Beberapa entri tidak seharusnya berubah menjadi riwayat release lama tanpa batas. Setiap digest yang diterima memperluas kumpulan representasi yang dapat lolos pemeriksaan. Jika build lama memuat kode yang tidak lagi semestinya dijalankan, mempertahankan digest-nya berarti mempertahankan jalur penerimaan untuk build tersebut.

Pemilihan algoritma juga penting ketika metadata memuat entri dengan fungsi hash berbeda. Pemrosesan browser mengikuti aturan SRI untuk memilih metadata yang berlaku, bukan memperlakukan setiap algoritma yang tercantum sebagai jalur downgrade independen. Tooling deployment perlu menghasilkan metadata sesuai spesifikasi yang berlaku dan memverifikasi hasilnya pada browser target.

Proses release yang lebih sederhana sering menghasilkan satu URL aset immutable beserta digest terkait, lalu memperbarui dokumen dalam transaksi release yang sama.

URL mutable menambah friksi pada release

SRI cocok dengan aset immutable. URL seperti:

/assets/vendor.4f31c2.js

dapat mengidentifikasi artifact tetap, sementara HTML membawa digest untuk artifact tersebut. Build baru mendapat identitas aset baru dan metadata baru.

URL mutable seperti:

https://cdn.example.net/library/latest.js

membentuk kontrak berbeda. Jika penyedia mengubah file sementara aplikasi masih membawa digest lama, browser menolak byte baru. Memperbarui file eksternal secara independen dari dokumen tidak kompatibel dengan content pin yang memang mengharapkan representasi tertentu.

Friksi tersebut berguna saat perubahan dependency secara diam-diam tidak dapat diterima. Konsekuensinya, tim memerlukan kepemilikan proses release untuk pembaruan digest, bukan menyalin metadata SRI satu kali lalu membiarkan konten di balik URL terus berubah.

Digest harus berasal dari build path yang tepercaya

Digest hanya menyatakan kesamaan dengan byte yang dipakai saat menghitungnya. Jika byte tersebut sudah berbahaya, SRI akan mempin konten berbahaya itu dengan tepat.

Langkah pembuatan digest karena itu berada di dalam batas software supply chain. Build pipeline dapat mengambil atau menghasilkan artifact yang dimaksud, memverifikasi provenance sesuai policy proyek, menghitung digest, lalu menghasilkan metadata HTML. Review kemudian dapat mencakup perubahan dependency sekaligus nilai integrity baru.

Menghasilkan digest dari apa pun yang kebetulan dikembalikan CDN production setelah release dapat membalik hubungan tersebut. Response CDN menjadi otoritas untuk konten yang diharapkan, bukan salinan distribusi dari artifact yang sudah disetujui.

Untuk library pihak ketiga, jalur distribusi yang versioned dan immutable membuat batas ini lebih mudah diaudit. Proyek tetap memerlukan review dependency, policy update, dan proses respons vulnerability seperti biasa; SRI tidak menggantikannya.

SRI dan CSP melindungi keputusan yang berbeda

Content Security Policy dan SRI sering diterapkan bersama, tetapi keduanya menjawab keputusan yang berbeda. CSP membatasi sumber resource atau jalur eksekusi script yang diizinkan dokumen. SRI memverifikasi bahwa resource yang diambil dan dilindungi cocok dengan konten yang disetujui.

Aturan CSP dapat mengizinkan script dari origin CDN. Izin pada level origin tersebut tidak mempin satu versi file. SRI dapat menambahkan constraint pada level byte untuk resource tertentu dari origin yang diizinkan.

Sebaliknya, digest SRI yang cocok tidak mengesampingkan CSP. Resource tetap harus memenuhi directive CSP yang berlaku dan pemeriksaan browser lainnya. Pelapisan kontrol ini berguna karena otorisasi sumber dan verifikasi konten menangani failure path yang berbeda.

Content pinning memindahkan tanggung jawab ke release engineering

SRI bekerja paling baik saat metadata integrity diperlakukan sebagai data release yang dihasilkan, bukan dekorasi yang dipelihara manual. Byte aset dan digest-nya perlu bergerak bersama. Reproducibility build, immutable naming, perilaku cache, konfigurasi CORS, dan prosedur rollback memengaruhi apakah pasangan tersebut tetap valid di production.

Rollback perlu ditangani secara eksplisit. Memulihkan dokumen HTML lama setelah aset pasangannya dihapus dapat gagal walaupun digest benar. Memulihkan aset lama di bawah URL mutable sementara HTML saat ini mengharapkan byte baru akan gagal karena alasan sebaliknya. Mempertahankan aset versioned selama rollback window yang didukung mencegah kedua mismatch tersebut.

Properti keamanannya tetap presisi: browser menerima resource yang dilindungi hanya saat representasi yang diambil memenuhi metadata integrity dan policy browser di sekitarnya mengizinkan pemuatan. Pemeriksaan itu dapat membatasi dampak perubahan tanpa izin pada host resource, tetapi hanya selama metadata, jalur pengiriman dokumen, dan proses release mempertahankan pernyataan tepercaya yang terpisah mengenai byte yang telah disetujui.