I am implementing a use case where for security reasons the Web server serving my application's assets would only send content of one particular [ES6] module to authorized users/clients only, going by the Authorization header supplied with the request. In other words any HTTP request for the module body, as originating with some import "./module-with-sensitive-data.js" statement (or import call) must only effectively succeed if and only if the server successfully authorizes the request by the provided Authorization header.

I am not using the "basic" HTTP authorization scheme, mind you. The authorization "bearer" token is issued by the Web service and the latter is the party tasked with resource access authorization.

Evidently, and to state for brevity what is probably obvious and what makes up my immediate problem, there seems to exist no facility to directly specify any additional headers beyond what the user agent would be supplying implicitly, with requests originating with import statements/calls like above.

The general form of this question, for posterity, can be said to be about two overlapping, hypothetical features: first, an ability to specify additional headers for import requests, and potentially other kinds of requests where currently no such provision is facilitated (link and script elements to name a few examples). Second, additional level of support by the user agent for authorization schemes other than "Basic" -- where like with the latter at least an "authorization realm" is defined and within which the user agent will at least supply some Authorization headers the application may be given some control of, one way or the other. Anyway, this is generalization, and like I said, for posterity and context.

To list some solutions to my immediate problem, solutions I have so far been considering, which all have non-trivial drawbacks:

1. Use a service worker to intercept HTTP requests and add Authorization header when appropriate. This should accomplish desired result, but brings in an entire service worker I now have to manage, with everything the API will demand with using it (activation? message passing?) Raising the bar for user agent feature support, again, to add a header for a module import request (granted, probably all user agents that support modules support service workers anyway).

2. Fetch the actual module resource using fetch, which would allow me to supply Authorization header, among others, for the request, then create a URL for the response blob with the URL.createObjectURL call, and supply that URL to the import procedure (or even import statement if it supports the kind of module specification URL). A drawback of this approach which I suspect will manifest is that the module won't be able to import other modules using relative paths, which it may want to potentially do (configuration is designed to be developed and maintained), because relative paths for import are resolved relative to the path of the module containing these, while the URL here is one of a "blob", with all the implications thereof.

3. Set a cookie, which I assume the user agent will be including with all the requests to the domain (subject to the cookie specification, of course).

Lastly, I could solve this with providing the authorization bearer (token) in the URL used in the import statement/call, but that is one thing I definitely want to avoid, regardless, for security reasons.

Is there any idiomatic way, preferably not involving any of the above solutions, to provide the Authorization header for when importing a module, or any headers beyond what a particular user agent module loader would be supplying implicitly? And if there isn't, would you consider any of the solutions described above as viable in practice?

To pre-empt the XY problem issue coming up -- me being unclear about what I am actually trying to do (Y) and instead asking how to specify headers for import statement/calls (X): as you may have surmised, the module may contain some amount of sensitive information, so it shouldn't be available without valid authorization. The information does not include passwords or keys, but may include personal information that can be misused for fingerprinting or profiling the service, and so it is a minor requirement from our security team to preferably only have the module available through authorization. The module acts as application's "configurator" and through it being essentially a script I can retain nearly arbitrary flexibility with regard to how and what the module is able to configure.