Re: XSS-Protection notes

On 2016-10-10 at 15:19 -0700, David Ross wrote:
> Here's another way to consider achieving the intended result...  There are certainly some bits of configuration that have gelled over the years and are now simply extra header cruft we might expect any reasonably secure page to serve.  Some examples to consider: 
>   - X-Content-Type-Options=nosniff
>   - The secure bit on cookies
> 
> With the move away from whitelists, best practice around CSP has changed recently and may continue to change going forward.  So we might want to avoid including CSP in any canonical security configuration.  Well, at least today, in 2016.
> 
> Consider something like:
> Security-Config: level=1; someConfigData=foo; otherConfigData=bar
> 
> Level 0 would be nothing.  (Same as not including this header.)
> Level 1 would be whatever we define in 2016.
> Level 2 would be whatever we decide to define in 2017.
> ...etc.
> 
> With this, developers could drop all the extra header cruft and follow more simplified security guidance.  An opt-in model means that we avoid automatically breaking pages.
> 
> We'd need to define a very clear philosophy about what we would include in level=N+1.  Being too aggressive would hurt adoption, while being too lax would pass on an opportunity to improve web security.  And of course we'd need to define level=N+1 periodically, perhaps at an annual meeting on a warm tropical island.  =)
> 
> 
> 
> Dave
> 
> 
> 

Hello Dave

I wouldn't use bare numbers there, but some kind of tags, like "legacy-2016", "modern-2016" or "safest-2017", which would alias the «security flags that should be expected from a modern application developed in 2016». Those expectations are what would need to be defined each year (as opposed to a paranoid flag that simply enables everything available at that point in time).
In addition to the defined levels for security configuration, it should also allow the developers to add or remove flags from a named configuration level. So that the developers could refer to a policy by the alias but add/remove a few flags.

Another point is what should be the behavior when a webpage requests a security config it knows nothing about (eg. the level corresponding to 2050). I guess the UA should apply the higher level [of that name] it knows about, instead of falling back to no security at all, but that would produce unintended results for old browsers if there's a version that drops a flag previously added.
> 

Best regards