source map HTTP request does not send cookie header

Question

Regarding source maps, I came across a strange behavior in chromium (build 181620). In my app I'm using minified jquery and after logging-in, I started seeing HTTP requests for "jquery.min.map" in server log file. Those requests were lacking cookie headers (all other requests were fine). Those requests are not even exposed in net tab in Developer tools (which doesn't bug me that much).

The point is, js files in this app are only supposed to be available to logged-in clients, so in this setup, the source maps either won't work or I'd have to change the location of source map to a public directory.

My question is: is this a desired behavior (meaning - source map requests should not send cookies) or is it a bug in Chromium?

Decastere

Answer 1

The String InspectorFrontendHost::loadResourceSynchronously(const String& url) implementation in InspectorFrontendHost.cpp, which is called for loading sourcemap resources, uses the DoNotAllowStoredCredentials flag, which I believe results in the behavior you are observing.

This method is potentially dangerous, so this flag is there for us (you) to be on the safe side and avoid leaking sensitive data.

As a side note, giving jquery.min.js out only to logged-in users (that is, not from a cookieless domain) is not a very good idea to deploy in the production environment. I;m not sure about your idea behind this, but if you definitely need to avoid giving the file to clients not visiting your site, you may resort to checking the Referer HTTP request header.

Praetor

Thanks for your answer, I just wanted to be sure that this behavior is intentional. I know that serving static files from cookieless domain would be better, but in this case jquery is just an example and does not need to be served this way. We only need to protect our own scripts for a corporate customer, so we would not expose any customer specific internals to the outside world. Btw, checking referrer is not the kind of security level we're looking for. – Decastere

Ok, I get the point now. One solution to this might be the security-through-obscurity approach: use random multi-bit Base36 (or something) stringified values in your resource names, which should be absolutely impossible to guess. They will be available only through the compiled JS source, which WILL be login-protected. – Praetor

Careful with the security through obscurity approach - unless you're using https, anyone can get the URL by sniffing traffic. Also, I don't see how passing a cookie is dangerous: The script can hit any domain it wants and it will send cookies. – Roice

@zaius: (a) you are correct about sniffing; I was thinking about "unaffiliated" people when suggesting that. If they run a targeted attack, they surely can do that. OTOH, they can sniff the script contents if it is not transmitted over https. (b) Yes, the script can, but if the DevTools get hacked, the consequences CAN be dramatic (I'm not stating they WILL be, though :)). – Praetor

The map files do not contain the code itself, so putting them into a public directory should not be a security problem. All I wanted, was to clarify whether the behavior I'm observing is intentional, which pretty much seems it is. – Decastere

@AlexanderPavlov - both good points. Hadn't thought about the map being run in the context of the devtool instead of the page. – Roice

Answer 2

I encountered this problem and became curious as to why certain authentication cookies were not sent in requests for .js.map files to our application.

In my testing using Chrome 71.0.3578.98, if the SameSite cookie atttribute is set to either strict or lax for a cookie, Chrome will not send that cookie when requesting the .js.map file. When there is no sameSite restriction, the cookie will be sent.

I'm not aware of any specification of the intended behavior.

Auriferous

See also discussion at bugs.chromium.org/p/chromium/issues/… – Auriferous