I liked using to old Observatory score to get management to understand that we should prioritize low-hanging security headers & it worked.
One of the advantages of Netlify I remember compared ho some other static hosting options is that you could set HTTP headers with a config file. Some you can set as meta tags, but many you cannot so you will get lower scores if hosting thru say Codeberg Pages or SourceHut Pages.
My biggest gripe is getting dinged for setting CSP to default-src: self" as there has beet a long-standing bug with Fx & SVG <use> links not working without it.
For a while, the observatory was used as a carrot & stick for internal Mozilla web pages to make them pass a baseline of security before deployment, while also trying to influence web developers to write more secure websites. It needs to be acknowledged that these are fundamentally different requirements.
Not every website out there needs the level of security that addons.m.o or accounts.firefox.com does.
The new iteration should be pushing less of a Mozilla-internal agenda, but we’re open to feedback. (Disclaimer: I don’t work on MDN or the observatory, but have helped reviewing the guidelines).
Btw, can you point to the Firefox / SVG issue you encountered?
I would agree. I don’t even think enforcing TLS is always the best thing at this point… even with the ISPs injecting ads & siphoning data but just for sheer accessibility.
My memory is a little vague since I just remember the mental note of always set default-src: 'self'; …. It was either using SVG sprites by <use href> to include a file, rendering it would be blocked by block by the CSP no matter which *-src values I set to 'self' …Or it could have been when I was trying use CSS inside an SVG breaking things. …I should probably retest if this is still a bug :)
My great colleague Tom saw this comment and found the bug. I’m afraid it’s non-trivial because the web standard is very unclear about <svg><use>.
Fun fact: The <use> element is almost unspecified. It’s not an iframe, it’s not an image. It’s some sort of copy behavior. I’ll see if I can nudge it along though. We should at least see how much work it is to align with other browsers and write the CSP bit into the spec? (Pls don’t hold your breath!)
I mean SVG sprites are very common… & should be preferred iconfonts in all cases, but this is the sort of thing that could get pushback from switching to SVGs
That is a lot of hashes for icons. Honestly I don’t see what’s that wrong with trusting yourself & disallowing the features you obviously aren’t using as it is often less text.
I liked using to old Observatory score to get management to understand that we should prioritize low-hanging security headers & it worked.
One of the advantages of Netlify I remember compared ho some other static hosting options is that you could set HTTP headers with a config file. Some you can set as meta tags, but many you cannot so you will get lower scores if hosting thru say Codeberg Pages or SourceHut Pages.
My biggest gripe is getting dinged for setting CSP to
default-src: self"as there has beet a long-standing bug with Fx & SVG<use>links not working without it.For a while, the observatory was used as a carrot & stick for internal Mozilla web pages to make them pass a baseline of security before deployment, while also trying to influence web developers to write more secure websites. It needs to be acknowledged that these are fundamentally different requirements.
Not every website out there needs the level of security that addons.m.o or accounts.firefox.com does.
The new iteration should be pushing less of a Mozilla-internal agenda, but we’re open to feedback. (Disclaimer: I don’t work on MDN or the observatory, but have helped reviewing the guidelines).
Btw, can you point to the Firefox / SVG issue you encountered?
I would agree. I don’t even think enforcing TLS is always the best thing at this point… even with the ISPs injecting ads & siphoning data but just for sheer accessibility.
My memory is a little vague since I just remember the mental note of always set
default-src: 'self'; …. It was either using SVG sprites by<use href>to include a file, rendering it would be blocked by block by the CSP no matter which*-srcvalues I set to'self'…Or it could have been when I was trying use CSS inside an SVG breaking things. …I should probably retest if this is still a bug :)My great colleague Tom saw this comment and found the bug. I’m afraid it’s non-trivial because the web standard is very unclear about
<svg><use>.Fun fact: The
<use>element is almost unspecified. It’s not an iframe, it’s not an image. It’s some sort of copy behavior. I’ll see if I can nudge it along though. We should at least see how much work it is to align with other browsers and write the CSP bit into the spec? (Pls don’t hold your breath!)oh wow yeah those semantics are weird now that I think about it… are there any other kinds of shadow roots that inherit styles from their parents?
I mean SVG sprites are very common… & should be preferred iconfonts in all cases, but this is the sort of thing that could get pushback from switching to SVGs
SVGs are common. CSP enforcing images is unfortunately not ;). Anyway, I’ll see what we can do.
You could add a sha256 to default-src instead of self
That is a lot of hashes for icons. Honestly I don’t see what’s that wrong with trusting yourself & disallowing the features you obviously aren’t using as it is often less text.
I was assuming you had one icons.svg and you were use-ing symbols in it
I put in my own (Surge.sh-hosted) website and got a remarkably low score. Neat!
Don’t mind the score too much! Just look over what gets checked and see if there is something to improve.