Hi (long post, like lukas very imho)
The thing that I like about modularizing based on threats is that it is much easier to explain to the web developer. I agree that this might make Browser vendors sad because (as Lukas said) "Threats just don't map to API's in a remotely neat 1 to many relationship." But , this lack of clear mapping is okay -- because that is a problem for browser vendors and spec writers, not of the Web Developers. The set consisting of spec writers + browser vendors is much much smaller than web developers. Consider the approach Brandon proposed (based on Browser API) and say the web site owner wants to protect against History enumeration. He now has to look at each module and see if it says something about History Enumeration and then come up with the subset of directives that he thinks will ensure protection against it. Compare to just saying 'safe-history' (or 'no-clickjacking' for click jacking etc.). I agree that this can _theoretically_ solved by having good documentation and explanations. But still , the final syntax the web site owner has to write is more complicated and that adds to possible errors , imho. You are also depending upon the documentation writers (do not assume people will only use the documentation you have written). Making the syntax and the explanation really simple is a nice goal as I think it protects against bad documentation too( there is really very few ways someone could misinterpret 'safe-history' in documentation/explanation). With a threat model based approach, the browser vendors and the spec writers are the ones who have to worry about all the nitty gritty details (what all things need to be done to prevent against 'history enumeration'?) And the sum of all this is made into one module. Ofcourse, this would require writing down the spec with more thought.[1] With regards, to new threats (that are somehow related or part of an older threat) popping up in the future. There are two approaches : you could give the threat a new name (e.g HistoryEnum2.0) and create a new directive , or include protection against that threat in the spec. Users of new browsers would be protected automatically. I like the latter approach more. Realize that for threats you haven't thought of at all, it doesn't matter how you have split CSP -- a user using an old browser and a web developer unaware of the threat , can not be protected. But with the latter approach, a user using a new browser (even with a web developer unaware of the threat) is protected. Regards Devdatta [1] An example : https://wiki.mozilla.org/Talk:Security/CSP/XSSModule _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
