Hi, Daniel,
It is far, far easier to add <meta>
support later if we need it than to remove a feature if we decide
it's not working out.
I see. That is good to know. I was rather anxious that it may had been the
other way around.
Not too worried about injected <meta> tags, we just have to make
sure it can only restrict the page further (which we already have to
do to support multiple HTTP headers).
I see. Yes, that is something I didn't think of yet... Sure, if a malicious
script gained access to the page it would lever existing CSP directives.
Good point..
Well, just brainstorming here, but CSP directives might be restricted to
only be considered if put before any other tag within <head>, during
parsing, before the <meta> directive becomes available to the DOM.
This is not an academic question, I've seen a lot of pages with
malware content injected above the normal page content. Is "best
effort" CSP enforcement good enough? Would we be fostering a false
sense of security by supporting <meta>?
Good question.
At the moment it's hard to imagine who would benefit from it, though.
Yes, I know there are a lot of people who can't change their headers, but
do those people run web applications that could suffer from XSS and other
attacks CSP addresses?
No, but it's the opposite way around: These users would be able to utilize
web services in pure client applications. That's the original idea behind my
vote. Please refer to Bugzilla Firefox suggestion #547437
(https://bugzilla.mozilla.org/show_bug.cgi?id=547437) for my original
suggestion on enabling XSS for client-only applications. This suggestion
would become obsolete with the help of CSP and <meta> tags.
Cheers,
Axel Dahmen
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
