manifest.json is potentially sensitive

[grncdr]

I'm not sure I'd classify this as a "security issue" as it's somewhat context sensitive, but I feel it deserves some consideration.

Webpacker uses the WebpackAssetsManifest plugin to communicate the generated filenames from webpack back to Rails for use in view helpers (javascripts_packs_with_chunks_tag etc). This manifest file will contain entrypoint information about all packs present in app/javascript/packs, and will be served on the web at /packs/manifest.json.

This could be considered a leak of private information if a user has multiple packs and expects that packs are only visible on "private" pages that include them using a view helper.

While obviously it's good practice to avoid committing anything sensitive into any JS file, there are degrees of sensitivity and a single Rails app commonly serves multiple audiences (e.g. users/admins). It might be fine for an authenticated admin to receive some information in a JS bundle that should not be exposed to all users. Currently a user (or security researcher) can trivially view the manifest.json and download all assets for all packs.

As far as I can tell, nothing in the default webpacker setup relies on being able to fetch manifest.json from the client, so I would propose that webpacker should change it's defaults to generate/read that file from another directory (e.g. /config/webpack/manifest.json).

What are your thoughts?

[rossta]

Thanks for your question.

We have precedent from a related issue regarding sourcemap defaults in Webpacker which can be summarized generally as "assets open by default."

While I agree with your assessment "nothing in the default webpacker setup relies on being able to fetch manifest.json from the client", I have found this feature useful for debugging on numerous occasions.

If you have access to settings on your webserver, it should be possible to disable public access though I understand that does require extra work on the developer and may not be feasible in all environments.

Perhaps making the manifest path easier to customize could be a compromise.

[grncdr]

A configuration option would be a good first step, but I still think the default should eventually be changed.

I feel that the issue here is qualitatively different from the one about source maps.* This is more like serving a default Apache index.html that lists all files in the assets tree. For me personally that is an unexpected behaviour, and does not align with other Rails defaults.

* something I've been doing and advocating for years now.

[jdelStrother]

I've got a PR for discussion up here - #3152 - see what you think.

[justin808]

This could be considered a leak of private information if a user has multiple packs and expects that packs are only visible on "private" pages that include them using a view helper.

@grncdr, please justify why this is a real security issue.

[jdelStrother]

I'm surprised it needs justifying. If Rails generated public/controllers.txt with a list of all the controllers used in the app, wouldn't that be considered a security issue?

[grncdr]

Disclaimer: I monkey-patched Webpacker in my codebase before opening this issue, and plan to migrate away from it in the future, so I personally don't care if webpacker ever does anything about this.

---

I work on a monolith with three different frontends, that all interact with the same underlying domain. By merging all pack manifests into a single publically accessible file, any user of more "public" frontends can easily find the JS that is intended only for the "private" ones.

Lucky for me, I've developed the habit of never put anything sensitive in any JS file, so my maximum theoretical exposure is limited to administrative URLs in e.g. fetch requests that should not be known to users. Those URLs are backed by controllers that enforce a correct security policy, but again, this boils down to my habits and vigilance. Given a less experienced team, some lapse in enforcement of authorization policy, or a misunderstanding of the privacy of webpacker assets, the consequences could be much worse.

The last kind of failure (misunderstanding) is really what I was hoping to address by opening the issue. I don't think most users expect that if they put code in packs/admin.js and only use it from views/layouts/admin.html.erb, that code is actually trivially discoverable to anybody who does a GET /packs/manifest.json. It's not necessarily a security issue in and of itself, but a surprising default that could easily bite somebody who doesn't (yet) apply maximum paranoia to all their web development tasks.