Concern regarding dynamic import as text

[garronej]

Hello,

First of all, thank you for the work on this proposal, I think the overall direction is excellent and the static, typed version of import ... with { type: "..." } makes a lot of sense.

However, I’d like to raise a security concern specifically around the dynamic form:

import(url, { type: "text" })

This is not about XSS attacks, those remain fully in scope regardless of this proposal.
The concern is about large-scale blind supply-chain attacks, and how dynamic import-as-text affects the defender’s ability to harden the runtime.

---

Background: hashed JS assets and blind discovery attacks

Modern web application build systems (Vite, Webpack, etc.) produce assets like:

/assets/index-CDtdNkf4.js
/assets/chunk-XYZ123.js

These filenames include a hash, which means an attacker who gains same-origin execution through a compromised dependency cannot know ahead of time which chunks contain interesting exports, such as:

• OIDC client instances
• authenticated fetch wrappers
• sensitive state machines

To discover these, a typical attack today must:

1. Parse the HTML to find the entrypoint
2. fetch that asset
3. Recursively discover its imports
4. Parse each chunk
5. Look for patterns corresponding to sensitive exports

Defenders can currently block step (2) by hardening fetch and other runtime built-ins very early, before any other application code runs.

This is extremely useful for libraries that intentionally treat the runtime as a hostile environment (for example, client-side OIDC implementations that aim to prevent token exfiltration even under supply-chain compromise).

---

Why dynamic import-as-text changes the threat model

Under this proposal, an attacker can do:

import(`/assets/index-CDtdNkf4.js`, { type: "text" })

And this cannot be prevented by:

• monkey-patching fetch
• freezing built-ins during early initialization
• guarding network primitives

Because dynamic import is a language-level mechanism that defenders cannot intercept.

This means:

The defender loses the ability to mitigate blind discovery attacks
by disabling runtime asset introspection.

Again: this does not impact targeted attacks (the attacker already knows the hash), but it does impact large-scale opportunistic attacks where the adversary does not know the asset graph in advance.

Today, this is still something defenders can block.
With dynamic import-as-text, they cannot.

---

Why this matters (concrete real-world case)

I am working on a client-side OIDC + PKCE implementation that treats the browser runtime as hostile and aims to prevent token exfiltration even if a dependency in the tree is compromised.

This kind of defensive approach requires limiting introspection of application assets.
If dynamic import-as-text is standardized without an interception/hardening mechanism, this class of protections becomes impossible.

This is a niche use-case, but it is one where security properties materially degrade under this proposal.

---

Summary

• Static import ... as text has no issue, its target must be known as build time, it's not levragable for discovring the assets graph.
• Dynamic import(url, { type: "text" }) introduces a new unpreventable attack surface: language-level introspection of hashed JS assets.
• This removes a defensive technique currently available to developers working in hostile runtime models.
• If possible, the dynamic form should allow hosts to intercept / disable it.

I realize this feedback is arriving at Stage 2, but the concern is not niche.
This affects any web application performing token exchange on the client, which includes a large portion of modern SPAs implementing OAuth/OIDC.

Today, most of the ecosystem implicitly treats “same-origin script execution = game over,” but large-scale NPM supply-chain compromises have shown that this assumption is increasingly unsafe. Some implementations (including mine) actively harden the runtime against hostile co-residents by disabling or mediating built-in primitives before any untrusted code loads.

Thank you for your time and for considering the security implications.

[bakkot]

The same concern applies to the import bytes proposal.

I agree that this does technically increase risk, but in my experience vanishingly few sites are actually successfully performing this kind of environment patching (notably: it is very hard to prevent a script from creating an iframe and reaching in to pull out an unpatched fetch), and the utility of the import bytes proposal is so great that it outweighs those concerns. The appropriate way for sites to be protecting against this class of attacks is with CSP or a service worker, not by trying to patch the runtime. (I say this as someone who is also doing runtime patching for similar reasons.)

[garronej]

Hello @bakkot,
Thank you for taking the time to respond.

but in my experience vanishingly few sites are actually successfully performing this kind of environment patching

This is a matter of fact, today, very few sites attempt deep environment hardening and even fewer succeed at making it remotly effective.
However, the context in which I'm raising this is not just theoretical.

I’m working on an OpenID Connect client (oidc-spa) that does implement full environment hardening in production through a Vite plugin.
The plugin guarantees that the hardening logic is the very first JavaScript executed on the page, and that all other modules lazily load after the environment is locked down.

There is active interest from the Keycloak team in using this client for their Admin and Account consoles.
Nothing is finalized, and I definitely don’t want to overstate this, but the discussions are real enough that it would be irresponsible for me not to raise concerns about upcoming platform features that could weaken its guarantees.

If adoption proceeds (and it is at least plausible), oidc-spa would no longer be niche. It would be deployed in high-security environments across many organizations.

notably: it is very hard to prevent a script from creating an iframe and reaching in to pull out an unpatched fetch

With a strict CSP like frame-src 'self';, this becomes effectively impossible.
Unless the compromised dependency manages to either inject a file into public/ (which is trivial to detect) or influence the build pipeline itself (which only a few trusted dependencies participate in), it cannot load a same-origin iframe capable of exposing an unpatched fetch.

The appropriate way for sites to be protecting against this class of attacks is with CSP

This is where I think there is a misunderstanding.
CSP and service workers do help with XSS, but the scenario I'm describing is not XSS.

This is a supply chain attack scenario:
trusted NPM code running in the same origin, with no CSP violations.
Because the code is first-party, CSP cannot restrict it, and the service worker can be unregistered or replaced by that same first-party code.

Environment hardening is the only viable mitigation strategy here.

---

Concrete real-world scenario

Let me describe a realistic attack that this proposal enables.

Assume a few months from now oidc-spa is used inside the Keycloak Admin Console (a React SPA).
This SPA performs token exchange on the client side.
Keycloak installations protect extremely sensitive systems (banks, Nvidia, gov portals, etc.).

Suppose one of the 5,038 NPM dependencies bundled in the Admin Console gets compromised by an exploit targetting specifically Keycloak.

oidc-spa today prevents the attacker from discovering the module graph by blocking requests to hashed JS assets.
This prevents the compromised dependency from locating the OIDC client entrypoint like:

const { dm as oidcClient } = await  import(`./${base}/assets/KcAdminUi-BV3D797K.js`);

Without knowing the correct hashed filename, the attacker cannot access the module that yield the token (placeholder) that enable to call the admin REST API.

With import(url, { type: "text" }) or { type: "bytes" }, this defense becomes ineffective:

• the attacker can dynamically scan all hashed assets,
• find the one exporting the OIDC client,
• dynamically import it.

At that point they can:

• create admin users,
• assign roles,
• change permissions,
• act as an administrator.

The exploit would work blindly, not targeting a specific build.
The attacker does not need to know the hash ahead of time they can discover them, these hashes are extremely likely to change between the moment the attack is crafted and the moment the compromised dependency is actually bundled this is why discoverability matters here.

Right now, oidc-spa prevents that kind of discovery.
The proposal removes that defense surface.

Note also that oidc-spa does not surface the token directly to the application, only placeholders this is why having an oidc-spa instance is enough to querty the Admin REST API but not enough to exfiltrate tokens.

---

Summary

• It is true that few apps perform strong hardening today.
• But this will not remain niche if Keycloak adopts oidc-spa.
• Supply-chain attacks are fundamentally different from XSS, CSP are powerless against supply chain attacks.
• Dynamic import(..., { type: "text" }) removes the ability to limit runtime module-graph discovery.

Thank you again for taking the feedback seriously.

[ljharb]

why couldn't you have your service worker also intercept text and byte import URLs?

[garronej]

Hello @ljharb, thanks, that’s a good suggestion in theory.

In practice though, oidc-spa intentionally does not register a service worker, for a few reasons:

1. Not a complete mitigation
   As far as I understand, even with a SW intercepting import(..., { type: "text" }), any module already fetched or evaluated would bypass the SW entirely.
   In practice, the chunk containing the OIDC client instance is almost always loaded before any compromised dependency runs, so import-as-text would still succeed.

2. Service workers are exclusive
   Only one service worker can control a given scope.
   If oidc-spa claimed that slot purely to intercept import() text/byte loads, it would immediately break compatibility with apps that rely on their own SW for caching, routing, telemetry, or offline support.
   That would make oidc-spa unusable for a large class of modern web apps.

3. Setup friction outside Vite
   While the Vite plugin could transparently generate and register a service worker, oidc-spa also supports non Vite environements, users can simply manually patch their entrypoint. Example for Angular
   Requiring every non-Vite user to also create and maintain a dedicated SW file under public/ would introduce significant extra friction compared to the current one-line entrypoint patch.

For these reasons, I don’t think a service worker is a practical or reliable place to enforce this protection.

[bakkot]

I have some miscellaneous comments, but one more significant than the others, so I'll lead with that:

With import(url, { type: "text" }) or { type: "bytes" }, this defense becomes ineffective: the attacker can dynamically scan all hashed assets, [...]

Can't you just make the hash longer? If you have the default 8 hexit (4 byte) hash, then sure, on a high-traffic site it might be feasible to request a large fraction of the two billion possible hashes by distributing the requests across many visitors, and thereby have one luck into discovering the sensitive one. If you instead use a 16 or 32 hexit hash, now it is not feasible. No one is enumerating 2^128 assets at a cost of one network request each.

Edit: or I guess maybe you're not worried about enumeration per se, since you're assuming they can discover the chunk names at runtime? If that's your threat model, please ignore this bit.

---

full environment hardening in production through a Vite plugin

If you're already relying on a Vite plugin, can you not have your plugin rewrite every dynamic import which is not passing a fixed string so that it goes through your enforcement logic first?

The plugin guarantees that the hardening logic is the very first JavaScript executed on the page, and that all other modules lazily load after the environment is locked down. [...] If adoption proceeds (and it is at least plausible), oidc-spa would no longer be niche. It would be deployed in high-security environments across many organizations.

It happens that I also work on a product which does instrumentation of the page environment, including a requirement that our script be first-run, so I'm familiar with this problem domain. It is, in some sense, theoretically possible to get security guarantees doing the thing you are doing. But also, I have to point out that given my experience of how websites are actually put together, the "first run" guarantee is operationally difficult to establish on many websites. Very few websites are actually composed of a single script output by vite.

With a strict CSP like frame-src 'self';, this becomes effectively impossible.

Well, yes, it is possible to have a sufficiently restrictive CSP in some environments. Do you also create such a CSP? I don't see any mention of it in your docs but I might have missed it.

This is where I think there is a misunderstanding. CSP and service workers do help with XSS, but the scenario I'm describing is not XSS.

CSP is designed to prevent exfiltration, although if you are concerned about them immediately using a token rather than exfiltrating it I agree this does not help.

Service workers allow you to interpose on all same-origin fetches, including those initiated by a dynamic import.

Because the code is first-party, CSP cannot restrict it, and the service worker can be unregistered or replaced by that same first-party code.

Only if you give them unrestricted access to navigator.serviceWorker or similar functionality. But your whole security model relies on being able to deny access to built-in APIs already. If you can do that, you can prevent such code from unregistering or replacing the service worker.

oidc-spa today prevents the attacker from discovering the module graph by blocking requests to hashed JS assets.

Uhhhh there are several ways around this. If this is an existing product whose security websites are depending on, do you have a preferred way for me to file security issues? If not I can just file public bugs.

As far as I understand, even with a SW intercepting import(..., { type: "text" }), any module already fetched or evaluated would bypass the SW entirely.

Only if you had previously loaded it with type: "text". Otherwise I am pretty sure it would create a separate instance in the module cache and so go through the service worker again. I'd have to confirm though.

[bakkot]

Apparently requests caused by this kind of import will have a Sec-Fetch-Dest: text header (or some similar value), so it is possible for the server to distinguish these from requests for scripts to be executed, and it could choose to reject them.

[garronej]

Hello @bakkot,

Sorry for the long-delayed reply. I wanted to take the time to research things properly so I wouldn’t waste anyone’s time with an issue that might be avoidable.

Apparently requests caused by this kind of import will have a Sec-Fetch-Dest: text header (or some similar value), so it is possible for the server to distinguish these from requests for scripts to be executed, and it could choose to reject them.

Thank you, this is fully satisfactory for the threat model I’m concerned with.
If this header is indeed present, I can close the issue.

---

To clarify the threat model:

I’m aiming to protect against highly targeted NPM supply-chain attacks directed at industry-standard applications deployed in hundreds of sensitive environments. There are very few real candidates for such an attack; the two I have in mind are Keycloak Admin Console and Onyxia.sh.

oidc-spa already prevents token exfiltration even if an attacker achieves same-origin code execution, that’s not what I’m worried about.
I’m trying to go one step further: prevent an attacker who successfully injects malicious code in the distribution build from being able to act on behalf of the user.

Today, no web app protects against this.
Backend session-cookie authentication is a non-starter, since cookies are attached to every outgoing request automatically.
But in client-side authentication, an attacker must first obtain the tools that enable authenticated requests. These utilities are usually exposed somewhere in hashed asset files. That’s why I care so much about preventing those hashes from being discoverable at runtime.

---

Responding to your points in detail:

Edit: or I guess maybe you're not worried about enumeration per se, since you're assuming they can discover the chunk names at runtime? If that's your threat model, please ignore this bit.

Yes, exactly. The mitigation specifically aims to prevent discovery of the hashed chunks by recursively crawling and parsing modules imported from the HTML.

Uhhhh there are several ways around this. If this is an existing product whose security websites are depending on, do you have a preferred way for me to file security issues? If not I can just file public bugs.

No worries, this has only just been released in a very recent version of oidc-spa, and no large system depends on it yet.

The angles I believe must be covered are:

• We must ensure no request can go to an attacker-controlled resource server; otherwise the attacker can simply perform the discovery there and return the results. (Currently only authed request are blocked)
• We must ensure no attacker-controlled iframes can be created, something CSP can enforce, though the library itself does not.
• Beyond that, if you see other angles I’ve missed, I’d greatly appreciate an issue or note on the matter. Only a few apps will ever care about this threat model, but precision matters here.

Only if you give them unrestricted access to navigator.serviceWorker…

You’re right on that point. But there are other practicallity concern with SW...

Service workers allow you to interpose on all same-origin fetches, including those initiated by a dynamic import.

Yes, though my understanding is that re-importing a module already in the module cache does not trigger a fetch.

Only if you had previously loaded it with type: "text".

If that’s indeed the case, that removes one objection to SW use, but we still face the “single interception layer” issue.
If I take that slot, I become incompatible with many apps. So not really practical.

If you're already relying on a Vite plugin, can you not have your plugin rewrite every dynamic import which is not passing a fixed string so that it goes through your enforcement logic first?

Technically possible, but hard to do robustly. It might significantly increases build time, and more importantly, the Vite plugin is only a convenience layer.
Non-Vite environments like Angular are supported through a manual entry-point patch. I want to preserve that property.

…the "first run" guarantee is operationally difficult to establish on many websites.

I’ve read your slides, and I believe every word.
Indeed, the constraints oidc-spa imposes to enable this defense are strict, and many large-scale applications won’t be able to meet them.
But the defense is entirely opt-in.

The idea is:

• Out of the box, oidc-spa follows all BCPs for SPA-based OIDC (incuding no token persistance).
• If you want, you can enable a mode that guarantees the token is never exposed at the application layer, but to enable this, you must:
  • avoid libraries that monkey-patch critical built-ins (String, fetch, XHR, etc.),
  • and have a single client entry point.

Users can decide whether these constraints fit their architecture.
I still believe there is real value in providing a way to ensure tokens cannot be accessed at the app layer, and many apps can meet these constraints without friction.

CSP is designed to prevent exfiltration.

CSP is powerless against NPM supply-chain attacks.

although if you are concerned about them immediately using a token rather than exfiltrating it I agree this does not help.

Right, tokens exposed to the app layer are placeholders anyway.
My concern is preventing malicious code from acting as the user while the attack is live.

---

Anyway, thank you very much, @bakkot, for the thorough review.
Your expertise in this domain is obvious, and any further feedback or weak spots you can spot in the defense model of oidc-spa would be extremely welcome.

If you’re willing, I’d love to see whether token access can actually be achieved under these constraints, before anything gets near Keycloak.

Here is a TanStack Start repo you can use to test:

npx gitpick keycloakify/oidc-spa/tree/main/examples/tanstack-start start-oidc
cd start-oidc
npm install
npm run dev

[bakkot]

Thank you, this is fully satisfactory for the threat model I’m concerned with.
If this header is indeed present, I can close the issue.

Unfortunately, now that I've had a chance to test it with type: "json", it looks like while the header should indeed be present, it is not a component of the HTTP cache key in Safari or Chrome, which means that if the script was already loaded as a regular script then a subsequent attempt to load it with type: "text" will be read from the browser cache instead of going to the server, meaning the server will not get a chance to decline to serve it.

This seems like the wrong behavior to me; I'll try to get clarity on the intended behavior from the WHATWG folks.

Beyond that, if you see other angles I’ve missed, I’d greatly appreciate an issue or note on the matter. Only a few apps will ever care about this threat model, but precision matters here.

Opened keycloakify/oidc-spa#123.

You also need to include workers in the threat model, not just iframes, for similar reasons.

[garronej]

Unfortunately, now that I've had a chance to test it with type: "json", it looks like while the header should indeed be present, it is not a component of the HTTP cache key in Safari or Chrome.
This means that if the script was already loaded as a regular module, a subsequent attempt to load it with type: "text" will be served from the browser cache instead of going to the server. As a result, the server does not get a chance to decline serving it.

Thank you very much for the thorough investigation, this is extremely helpful.
Reopening the issue, since this behavior undermines the only remaining mitigation strategy I was counting on implementing when I previously closed it.

And @bakkot: sincerely, thank you as well for the issue you oppened on oidc-spa.
I fully realize I'm being a bit bold by interjecting at this stage, especially before I’ve completely covered all current attack vectors. But this proposal genuinely determines whether my security model is viable or dead on arrival, so I appreciate you taking the concern seriously.