CSP Directives Should Be Structured #274
Description
A directive such as 'unsafe-eval' is useful during the transition period before full Web security is a reality. But 'unsafe-eval' and other insecure rule exceptions should not apply to all code in a website, and specifically should not apply users' coding, coding that can more or less easily be changed to comply.
Currently, 'unsafe-eval' applies to all domains of a type in the entire website.
I propose that it should apply only to frequently or universally used Web ciode that is not easy to modify. To specify this requires a structured CSP language, not just several flat lists (default-script, etc.).
For example, if I own a small website, with the proper CSP-type tools to guide me I can quickly get it into compliance with CSP security standards. But I have no control over Google Analytics, for example, which currently uses unsafe evals. What I want during transition is high standards for myself, but very low standards for Google Analytics and other major libraries of code that may take months or years before they are in compliance.
A structured CSP language would permit marking code from Google Analytics as 'unsafe-eval' permissable, while 'self' code would not be 'unsafe-eval' permissable.
This example is just for illustration; I don't mean any criticism or accusation of insecurity in connection with specific Google Analytics algorithms or code. It is certainly possible to use generally insecure mechanisms carefully and securely, and I assume that Google indeed does so.