Ideally we would have no inline JS which would allow us to tighten down our Content Security Policy. That's going to be hard to remove entirely, but if we can remove all of the pages that specify <script> we can use a nonce to cover the ones included in output_header() and slim_header() via $extra_args["js_data"] (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_inline_script).
So we should:
- Move JS code to
.js files when possible
- Any code we can't move to
.js. files needs to be lifted into $extra_args["js_data"] so it can be covered under a (to-be-developed) nonce mechanism.
Closing this ticket would be having no <script> content in PHP code outside that created in html_page_common.inc and a nonce mechanism cover the header-inserted code.
Ideally we would have no inline JS which would allow us to tighten down our Content Security Policy. That's going to be hard to remove entirely, but if we can remove all of the pages that specify
<script>we can use anonceto cover the ones included inoutput_header()andslim_header()via$extra_args["js_data"](see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_inline_script).So we should:
.jsfiles when possible.js. files needs to be lifted into$extra_args["js_data"]so it can be covered under a (to-be-developed) nonce mechanism.Closing this ticket would be having no
<script>content in PHP code outside that created inhtml_page_common.incand a nonce mechanism cover the header-inserted code.