Partly. The integrity attribute works on script elements, including module scripts, and on modulepreload links. For modules fetched by import statements, MDN documents an integrity key inside import maps. It says to check the compatibility table, so test your target browsers before you rely on it.
The three places a module can load from
| How the module loads | Where integrity goes |
|---|---|
| A script element with type module | The integrity attribute on that element |
| A link with rel modulepreload | The integrity attribute on the link |
| A static import or a dynamic import call | The integrity key in an import map |
MDN's SRI guide lists script elements and link elements with rel stylesheet, preload or modulepreload as supported. It does not mention the import call, which is why the import map matters.
What an import map does
An import map is JSON inside a script element of type importmap. It tells the browser how to resolve module names in import statements and import calls. Its integrity key maps module URLs to SRI hash strings, in the same format as the attribute. MDN says it applies to both static and dynamic imports.
<script type="importmap">
{
"imports": { "square": "./modules/shapes/square.js" },
"integrity": {
"./modules/shapes/square.js": "sha384-REPLACE_WITH_REAL_HASH"
}
}
</script>
The hash above is a placeholder. Generate yours from the exact file, for example with the openssl command in MDN's guide.
Rules worth remembering
- Order matters. The import map must be processed before any module that uses a mapped name.
- Explicit wins. If a fetch already has integrity metadata, the map's value is not applied.
- Scope is limited. Import maps do not apply to the src of a script element, or to workers and worklets, so those need their own handling.
- The import map script element itself must not carry src, integrity or crossorigin.
- Module scripts require CORS for cross-origin fetches, so the server must send the right headers.
A practical approach
- Pin exact versions of every remote module URL.
- Generate hashes for each file at build time, not by hand.
- Emit the import map from your build so hashes and URLs stay in sync.
- Test in each browser you support, including an old one, with a deliberately wrong hash to confirm it blocks.
- Keep a fallback plan, because MDN warns that support for parts of import maps varies.
If you bundle your code, you may not need any of this for your own modules. The bundle is one file you serve yourself. The import map approach shines when you load a few modules directly from a remote host.
Related reading
For the basics, see how to add Subresource Integrity to scripts and stylesheets. To enforce integrity everywhere, see the Integrity-Policy header explained.
Safeguard's dependency scanning covers the npm packages you bundle, so the modules you do not load remotely still get advisory checks. Try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need integrity if I bundle everything into one file?
Not for the bundled modules, since you serve that file yourself. Use it for any script loaded from another host.
What if a browser ignores the import map integrity key?
The module loads without a hash check. Treat the key as one layer and add CSP and exact version pinning.
Sources
- MDN, import maps: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script/type/importmap
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
- MDN, script element: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script
Last reviewed: 19 October 2026.
