
An Introduction to Content Security Policy - tambourine_man
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
======
dmix
As effective as CSP can be I always felt this was an awkward way to achieve
the goal. The API is not very intuitive. Possibly due to the limitations of
being an HTTP header or the broad scope offering fine-grained control for
every type of element (CSS, JS iframes, etc). It seems to be trying to appease
every type of situation.

Just look at how OWASP describes it:

> Content Security Policy _requires careful tuning and precise definition of
> the policy_. If enabled, CSP has significant impact on the way browser
> renders pages

If they want wide adoption they should really keep it simple. How often would
sites need multiple URL whitelists for each (img/script/stylesheet)? A single
whitelist would be fine. This is what I would have proposed:

    
    
        Content-Security-Whitelist: self analytics.google.com mixpanel.com;
        Content-Security-Policy: 
                scripts=<whitelist|*|none>; 
                styles=<whitelist|*|none>;  
                img=<whitelist|*|none>; 
                plugins=<whitelist|*|none>; 
                iframes=<whitelist|*|none>;      
                inline-scripts=<allow|deny>; 
                inline-styles=<allow|deny>; 
                insecure-requests=<upgrade|allow|deny>;

------
jonwayne
I wrote a flask extension that makes it a little easier to set these headers:

[https://github.com/GoogleCloudPlatform/flask-
talisman](https://github.com/GoogleCloudPlatform/flask-talisman)

