←back to thread

Hardening the Firefox Front End with Content Security Policies

(attackanddefense.dev)
182 points evilpie | 3 comments | 09 Apr 25 09:34 UTC | HN request time: 0s | source
Show context
theandrewbailey ◴[09 Apr 25 11:13 UTC] No.43630873[source]▶
CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though <link>, and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.
replies(6): >>43630934 #>>43631184 #>>43631253 #>>43632334 #>>43633733 #>>43635528 #
athanagor2 ◴[09 Apr 25 12:21 UTC] No.43631253[source]▶
Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol
replies(4): >>43631299 #>>43631348 #>>43631357 #>>43633910 #
1. bryanrasmussen ◴[09 Apr 25 12:34 UTC] No.43631348[source]▶
sounds weird to me too, although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script - about the only way I can think of it being bad.
replies(1): >>43634318 #
2. diggan ◴[09 Apr 25 16:49 UTC] No.43634318[source]▶
> although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script

Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical <script> tag.

In short, CORS applies to network requests made by scripts, not to the scripts themselves

replies(1): >>43634536 #
3. bryanrasmussen ◴[09 Apr 25 17:06 UTC] No.43634536[source]▶
ah yeah, sorry wasn't thinking clearly.