4 ms·
That doesn't really provide any meaningful reassurance when the code in the browser can still do anything it wants, such as stealing auth tokens, keylogging, et
by ljm 6y ago
That doesn't really provide any meaningful reassurance when the code in the browser can still do anything it wants, such as stealing auth tokens, keylogging, etc. It's a different class of vulnerabilities and if you happened to be doing fancy SPA stuff, you could reasonably get a double bonanza by getting into the server environment on the SSR side.
- diggan 6y agonpm scripts having same-as-you access to your computer in a linux-like environment is very different than JS running inside the browser sandbox though. By default its scoped to the origin its running on and with some additional header/html tags, can be further limited to just running your specific code and no get/post to other origins, and more. So while running 3rd party code without inspecting it closely is always risky, its a lot more risky to run via node than via the browser js engine.
- catears 6y agoThere is already protection against this form of attack in the browser with CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- the_duke 6y agoCORS doesn't help with compromised client code, since the CORS headers would allow access anyway. CSP [1] can help by preventing malicious code to leak data to third parties, but it's far from trivial to close all loopholes. Especially with the myriad of tracking and other third party scripts most sites/apps use. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...