In the modular approach, this is not true. You simply send this header: X-Content-Security-Policy: safe-history
The requirements to remove inline script, eval, etc aren't present because you haven't opted into the XSSModule. You can, of course, combine them using this sort of policy: X-Content-Security-Policy: safe-history, block-xss but you certainly don't have to. Adam On Tue, Oct 20, 2009 at 1:59 PM, Devdatta <dev.akh...@gmail.com> wrote: > The history enumeration threat is a simple threat with a simple > solution. Opting into Safe History protection shouldn't require me to > do all the work of opting into CSP. In addition, I don't see any > infrastructure that is needed by this feature that is in common with > CSP. > > Lets say I am a website adminstrator, and I am concerned about this > particular threat . Opting into CSP involves a lot of work - > understanding the spec, noting down all the domains that interact > everywhere on my site, removing inline scripts and evals and > javascript URLs to corrected code etc. etc. My fear is that this will > make admins write policies that are too lenient (say with allow-eval) > , just to get the safe history feature. > > Cheers > Devdatta > > 2009/10/20 Adam Barth <abarth-mozi...@adambarth.com>: >> On Tue, Oct 20, 2009 at 12:50 PM, Devdatta <dev.akh...@gmail.com> wrote: >>> Regarding , History enumeration -- I don't see why it should be part >>> of CSP. A separate header - X-Safe-History can be used. >> >> I think one of the goals of CSP is to avoid having one-off HTTP >> headers for each threat we'd like to mitigate. Combining different >> directives into a single policy mechanism has advantages: >> >> 1) It's easier for web site operators to manage one policy. >> 2) The directives can share common infrastructure, like the reporting >> facilities. >> >> Adam >> > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
