Core screens that work with a nonce-based CSP (no inline JavaScript)

[anabobillo3]

With the Nonce option of the System - HTTP Headers plugin turned on, browsers ignore 'unsafe-inline', so every inline event handler (onclick, onchange, ...) and every javascript: link in core stops working. #45770 reports two of them on the frontend category list. Part of this is already done or open: #39730 (JGrid), #45910 (Grid::id), #48523 (frontend sort headings) and #48737 (check all, limit box, administrator pagination).

What is left on 6.3-dev:

• about 130 inline event handlers in PHP layouts, helpers and views (toolbar layouts, administrator modals, component edit views, some site views and modules, the installation app)
• about 40 onchange/onclick attributes on form fields in the core XML forms
• about 25 javascript: URLs
• two new Function() calls in media JavaScript, which need 'unsafe-eval'

Proposal

Convert them area by area, the way #45910 and #48523 do: classes and data attributes handled by scripts core already has (mostly list-view), with each helper loading the script it needs. Where the inline code comes from something an extension can pass in (a custom action for Grid::checkall, $button['onclick'] in the login module and view, onchange on form fields), it keeps working as it does today, so nothing breaks for extensions.

One PR per area, so each one stays small enough to test:

1. List helpers ([6.3] List views: check all, limit box and pagination without inline JavaScript #48737)
2. Toolbar and shared layouts
3. Administrator modals (the select links and the association buttons)
4. Administrator component views
5. Site views, modules and the installation app
6. Form fields: the core forms stop using onchange/onclick, while the field attributes stay for extensions. This one changes how fields are used, so I would like feedback on it here before writing it.
7. A strict preset in the HTTP Headers plugin, and a system test that opens the core screens with it and fails on a CSP violation, so new inline handlers do not creep back in.

Why

A nonce-based policy without 'unsafe-inline' is one of the best protections a browser can give against XSS, but today it can't be turned on without breaking much of the administrator. Once this is done, a site can enable it from the plugin.

Questions

• Is there other work planned (on the toolbar, the list views or the administrator template, for example) that this should line up with?
• Is one PR per area a good size for testing, or would you prefer them smaller or larger?

[brianteeman]

https://accessibility-project.joomla.org/docs/milestones/

[anabobillo3]

Thanks, that helps. Of those milestones, the closest to this seem to be 2a/2b (design system components), 7b/7c (transversal features) and 3b (the backend template build, from January).

This series only changes how the existing controls are wired: each inline handler becomes a class or data- attribute that a core script reads, and the markup and styles otherwise stay as they are. So it should carry over into the new components and templates rather than compete with them, and those can start from markup that has no inline JavaScript.

If the design system work already has a convention for these hooks (class names or data- attributes), I'll follow it in the next PRs.