Add a note about 'strict-dynamic' allowing injections into non-parser-inserted script URIs to be exploitable

[arturjanc]

In the Usage of "'strict-dynamic'" section (https://w3c.github.io/webappsec-csp/#strict-dynamic-usage) we should describe the relaxation of the policy if the attacker controls the URL of a script loaded dynamically via a non-parser-inserted API.

Maybe something like this (rough draft):
"""
Note: With 'strict-dynamic', scripts created at runtime via APIs such as createElement() will be allowed to execute by the policy. If the location of a dynamically created script is controlled by an attacker, the policy will permit the loading of arbitrary external scripts. Developers using applications or frameworks which tend to determine script locations at runtime should audit the uses of non-parser-inserted APIs to add scripts, and make sure they are not invoked with untrusted data.
"""

Context: http://blog.kotowicz.net/2016/06/reflections-on-trusting-csp.html (+ comment thread)

[arturjanc]

Perhaps also add a note about the possibility of using two separate policies to enforce both a nonce-based policy with 'strict-dynamic' and a URL whitelist?

"""
Note: Setting a policy with 'strict-dynamic' will cause browsers to ignore URLs in the script-src whitelist and allow the execution of all scripts whitelisted by a nonce, hash, or added at runtime via a non-parser-inserted API. Due to this, a policy with 'strict-dynamic' cannot restrict the locations of scripts allowed to load by the application. In situations where it's desirable to invoke the /trust propagation/ aspect of 'strict-dynamic' and enforce URL-based restrictions on the locations of scripts, the application can simultaneously set two separate CSP policies:
Content-Security-Policy: script-src example.org
Content-Security-Policy: script-src 'strict-dynamic' https:
"""

(I'm not entirely sure about this, especially the example policies since they're not backwards compatible, but just as a start...)