<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Subresource Integrity on Nalar</title>
    <link>https://nalar.dev/tags/subresource-integrity/</link>
    <description>Recent content in Subresource Integrity on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 10 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/subresource-integrity/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Pin Third-Party Browser Assets with Subresource Integrity</title>
      <link>https://nalar.dev/pin-third-party-browser-assets-with-subresource-integrity/</link>
      <pubDate>Thu, 10 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/pin-third-party-browser-assets-with-subresource-integrity/</guid>
      <description>&lt;p&gt;Loading JavaScript directly from another organisation&amp;rsquo;s server creates a security dependency that is easy to overlook. Your page may contain only a short &lt;code&gt;&amp;lt;script&amp;gt;&lt;/code&gt; tag, but the downloaded file executes with the privileges that your site gives that script. If the file at that URL changes unexpectedly, your users can receive code you never reviewed or deployed.&lt;/p&gt;&#xA;&lt;p&gt;Subresource Integrity (SRI) gives the browser an expected cryptographic hash for a fetched resource. The browser hashes the bytes it receives and loads the resource only when the result matches the declared value. That turns “load whatever this URL serves” into “load the specific content I approved from this URL.”&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
