Note that the further I went down the sandboxing rabbit-hole, the more questions it raised about whether it's more or actually less secure. The main problem is that in order to work, these tools often use a setuid binary, which actually has more permissions than most users. So in theory if a sandboxed app finds an exploit in the sandboxing program (like firejail) that you're running inside, you could actually be worse off than it breaking out of whatever program you're sandboxing in the first place.
I think in this case though where you're more concerned about the very real problem of websites accessing localhost, it probably outweighs the maybe of a firejail exploit.
> these tools often use a setuid binary, which actually has more permissions than most users.
These tools often drop privileges as soon as the program is executed, in firejail, there's also an option to disalble root entirely within a namespace.
Interesting point, I hadn't made it that far down the rabbit hole. I agree that it's not a complete solution, and possible risks of exploiting the sandbox itself should be taken into account on a case-by-case basis.
It's also possible to run a web browser in a docker container which can be interacted with on the host OS. This avoids the permissions issues with solutions like firejail:
I think in this case though where you're more concerned about the very real problem of websites accessing localhost, it probably outweighs the maybe of a firejail exploit.