To reiterate, the package staringatlights:fast-render has a cookies based solution for SSR which works today.
1 Like
I have had some discussions with ChatGPT and I added the following on my server.
// Sets Content Security Policy to enhance security by restricting resource loading and execution:
// - `default-src 'self'`: Only allows resources (e.g., scripts, styles, images) from the same origin as the page.
// - `script-src 'self' 'unsafe-inline' 'unsafe-eval'`: Allows scripts from the same origin,
// permits inline scripts, and allows the use of eval().
// - Use of 'unsafe-inline' for scripts increases the risk of XSS attacks but may be necessary for compatibility.
// - Use of 'unsafe-eval' allows JavaScript's eval() function and similar methods, which can execute arbitrary strings as code.
// This can significantly increase the risk of security vulnerabilities such as XSS and should be avoided if possible.
// - `style-src 'self' 'unsafe-inline'`: Allows stylesheets from the same origin and permits inline styles.
// - 'Unsafe-inline' for styles is considered less risky than for scripts but should be minimized if possible.
// Note: 'unsafe-inline' and 'unsafe-eval' can expose the site to cross-site scripting (XSS) vulnerabilities by allowing
// the execution of arbitrary code. Consider refactoring to remove inline usage and 'eval()' or implementing
// additional security measures like nonces or hashes to enhance protection against XSS attacks.
res.setHeader(
'Content-Security-Policy',
"default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
);
This allows the client to only talk to the source (meteor) server and not to any other server. This makes it impossible to send the token stored in LocalStorage to another server.
Since we have an isomorphic app, the server could send secrets to a malicious site. Therefore, we use very strict network policies on the server.
My conclusion is: Using Local Storage can be unsafe if you have malicious code injected via some deeply nested npm dependency, using a good Content-Security-Policy can reduce the risk. You have to also make sure that the server has restricted access to the interned, else it could send secrets to a malicious site…
4 Likes
This is pretty basic, but should work. The Helmet package and the Meteor’s Browser Policy packages should handle this and more.
I highly recommend everyone to study on this and adjust it further for your apps. Lot of it will be trial and error, but if you want more secure app, then this is a must.
3 Likes
This should be addressed in the security guide!
1 Like
The documentation on atmosphere is difficult to read and there is no link to meteor/packages/browser-policy, and therefore I would not have considered the package (a package without source is suspicious to me)