Bugzilla

From Alex's comment, it sounds like we should try to move fetching the sourcemap to the DevTools server and try fetching the sourcemap as the page itself, with the correct principal. And potentially add a parent process / higher privileges fallback in the parent, but still on the server. That solution would be compatible with remote debugging which is not really the case with the current one.

However the issue we need to fix here is not just about fetching the initial sourcemap, it also applies to all the files listed in the sourcemap. For instance, if I modify my example mentioned above to list `file:///etc/passwd` in the `sources` property of the sourcemap, then we will actually show the content of this file in the StyleEditor.

So in theory any resource load linked to sourcemaps should be done as the page on the DevTools server. Which is the solution we had initially, but we moved this to a DevTools client worker years ago because of performance reasons (Bug 1289570, Bug 1349354). To me it feels risky to change the architecture back to a server side one, as we might end up with the same issues as with the original server implementation. At least I don't feel confident about it.

For shorter term fixes, we could try to implement:
- Add manual checks on the URLs and disallow file/chrome/resource. Maybe except in certain conditions? eg if the original CSS/JS file itself was served from such a protocol?
- Use the correct principal. But this will not work with remote debugging, and I need to check if we can pass a principal to a worker

From Alex's comment, it sounds like we should try to move fetching the sourcemap to the DevTools server and try fetching the sourcemap as the page itself, with the correct principal. And potentially add a higher privileges fallback in the parent process, but still on the server. That solution would be compatible with remote debugging which is not really the case with the current one.

However the issue we need to fix here is not just about fetching the initial sourcemap, it also applies to all the files listed in the sourcemap. For instance, if I modify my example mentioned above to list `file:///etc/passwd` in the `sources` property of the sourcemap, then we will actually show the content of this file in the StyleEditor.

So in theory any resource load linked to sourcemaps should be done as the page on the DevTools server. Which is the solution we had initially, but we moved this to a DevTools client worker years ago because of performance reasons (Bug 1289570, Bug 1349354). To me it feels risky to change the architecture back to a server side one, as we might end up with the same issues as with the original server implementation. At least I don't feel confident about it.

For shorter term fixes, we could try to implement:
- Add manual checks on the URLs and disallow file/chrome/resource. Maybe except in certain conditions? eg if the original CSS/JS file itself was served from such a protocol?
- Use the correct principal. But this will not work with remote debugging, and I need to check if we can pass a principal to a worker