<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Keamanan Web on Nalar</title>
    <link>https://nalar.dev/id/tags/keamanan-web/</link>
    <description>Recent content in Keamanan Web on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Sat, 19 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/keamanan-web/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Header Fetch Metadata Membentuk Batas Request Lintas Situs di Sisi Server</title>
      <link>https://nalar.dev/id/header-fetch-metadata-membentuk-batas-request-lintas-situs-di-sisi-server/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/header-fetch-metadata-membentuk-batas-request-lintas-situs-di-sisi-server/</guid>
      <description>&lt;p&gt;Browser dapat mengirim request terautentikasi ke sebuah situs dari dokumen yang di-host di tempat lain. Cookie dapat menyertai request tersebut sesuai atribut cookie, sementara same-origin policy tetap dapat mencegah halaman pemicu membaca respons. Bagi server, perbedaan ini penting: pemblokiran akses terhadap respons tidak selalu menghentikan request lintas situs agar tidak mencapai endpoint.&lt;/p&gt;&#xA;&lt;p&gt;Fetch Metadata menambahkan konteks request ke batas ini. User agent yang mendukung mekanisme tersebut memasang header request &lt;code&gt;Sec-Fetch-*&lt;/code&gt; yang menjelaskan relasi serta properti request agar dapat dievaluasi server sebelum logika aplikasi menjalankan tindakan sensitif. Kebijakan dapat menolak request karena bersifat lintas situs, sekaligus mempertahankan alur navigasi atau resource publik tertentu.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Nonce CSP dan strict-dynamic Memindahkan Kepercayaan Skrip ke Batas Bootstrap</title>
      <link>https://nalar.dev/id/nonce-csp-dan-strict-dynamic-memindahkan-kepercayaan-skrip-ke-batas-bootstrap/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/nonce-csp-dan-strict-dynamic-memindahkan-kepercayaan-skrip-ke-batas-bootstrap/</guid>
      <description>&lt;p&gt;Content Security Policy dapat berisi daftar panjang host skrip yang diizinkan tetapi tetap memberikan kewenangan eksekusi lebih luas daripada yang dimaksud pembuat aplikasi. Sumber host seperti &lt;code&gt;https://cdn.example.net&lt;/code&gt; mengizinkan resource skrip yang cocok dari origin tersebut; aturan itu tidak menyatakan respons individual atau keputusan aplikasi mana yang dipercaya. Saat host yang diizinkan juga menyajikan file yang dikendalikan pengguna, endpoint JSONP lama, atau resource executable lain di luar set yang dimaksud aplikasi, batas berbasis host dapat menjadi terlalu luas.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CSP Strict Dynamic Memindahkan Trust Script dari Daftar Host ke Root dengan Nonce</title>
      <link>https://nalar.dev/id/csp-strict-dynamic-memindahkan-trust-script-dari-daftar-host-ke-root-dengan-nonce/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/csp-strict-dynamic-memindahkan-trust-script-dari-daftar-host-ke-root-dengan-nonce/</guid>
      <description>&lt;h1 id=&#34;csp-strict-dynamic-memindahkan-trust-script-dari-daftar-host-ke-root-dengan-nonce&#34;&gt;CSP Strict Dynamic Memindahkan Trust Script dari Daftar Host ke Root dengan Nonce&lt;/h1&gt;&#xA;&lt;p&gt;Halaman production dapat memakai kebijakan &lt;code&gt;script-src&lt;/code&gt; yang ketat tetapi tetap bergantung pada bootstrap script yang membuat elemen script tambahan saat runtime. Host allowlist menangani arsitektur ini dengan mencantumkan setiap origin script yang diizinkan. Akibatnya, daftar tersebut terikat pada topologi deployment: memindahkan dependency ke host lain dapat memerlukan perubahan kebijakan, sedangkan mengizinkan host yang terlalu luas dapat memberi izin pada lebih banyak konten executable daripada yang dimaksud aplikasi.&lt;/p&gt;</description>
    </item>
    <item>
      <title>DNS Rebinding Mempertahankan Origin Web Sambil Mengubah Tujuan Jaringan</title>
      <link>https://nalar.dev/id/dns-rebinding-mempertahankan-origin-web-sambil-mengubah-tujuan-jaringan/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/dns-rebinding-mempertahankan-origin-web-sambil-mengubah-tujuan-jaringan/</guid>
      <description>&lt;h1 id=&#34;dns-rebinding-mempertahankan-origin-web-sambil-mengubah-tujuan-jaringan&#34;&gt;DNS Rebinding Mempertahankan Origin Web Sambil Mengubah Tujuan Jaringan&lt;/h1&gt;&#xA;&lt;p&gt;Browser dapat memuat konten aktif dari server publik, mempertahankan konten tersebut dalam web origin yang sama, lalu mengirim request berikutnya dengan hostname yang sama ke alamat privat. Tuple origin tidak berubah. Tujuan jaringannya yang berubah.&lt;/p&gt;&#xA;&lt;p&gt;Ketidakselarasan inilah inti DNS rebinding. Web origin pada dasarnya diidentifikasi oleh scheme, host, dan port, sedangkan DNS memetakan hostname ke alamat jaringan yang berada di luar tuple tersebut. Ketika nama yang dikendalikan penyerang menghasilkan resolusi berbeda dari waktu ke waktu, pemeriksaan origin dan pemeriksaan lokasi jaringan dapat menggambarkan dua batas keamanan yang berbeda.&lt;/p&gt;</description>
    </item>
    <item>
      <title>DNS Rebinding Mempertahankan Web Origin sambil Mengubah Tujuan Jaringan</title>
      <link>https://nalar.dev/id/dns-rebinding-mempertahankan-web-origin-sambil-mengubah-tujuan-jaringan/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/dns-rebinding-mempertahankan-web-origin-sambil-mengubah-tujuan-jaringan/</guid>
      <description>&lt;h1 id=&#34;dns-rebinding-mempertahankan-web-origin-sambil-mengubah-tujuan-jaringan&#34;&gt;DNS Rebinding Mempertahankan Web Origin sambil Mengubah Tujuan Jaringan&lt;/h1&gt;&#xA;&lt;p&gt;Browser dapat memuat active content dari server publik, mempertahankan content tersebut dalam web origin yang sama, lalu mengirim request berikutnya dengan hostname yang sama ke alamat privat. Tuple origin tidak berubah. Tujuan jaringannya yang berubah.&lt;/p&gt;&#xA;&lt;p&gt;Ketidaksesuaian inilah inti DNS rebinding. Web origin terutama diidentifikasi oleh scheme, host, dan port, sedangkan DNS memetakan hostname ke alamat jaringan di luar tuple tersebut. Ketika nama yang dikendalikan attacker menghasilkan resolusi berbeda dari waktu ke waktu, origin check dan network-location check dapat menggambarkan dua security boundary yang berbeda.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
