is this for 4.0?

@zero-24 did you add this to the http headers plugin?

No. That what hopefully get shipped with the CSP things in Joomla 4.0 has nothing todo with sub resource integrity I think you mean the nonces thing? That is just about marking sure the inline scripts you want to be whitelisted still work without allowing any inline scripts to be executed.

This here make sure that the scripts you import from remote servers matches the hash you have set. CSP just take care about the sever itself not what script(s) you want to load from there.

In the past I was thinking about a way to implement that but we get a problem here. We can add the support to add the integrity attribute but not the value. Why? Because the whole point of this thing is that you have checked the remote source and said you trust this exact version (represented by the hash). When Joomla would automatically generate them on any page reload this would just be the latest version and the benefit would be gone.

The only way to workaround that would be a new database table that holds all the infos about all resouces we want to load. But this also means that in case there are changes on the remote site the script etc is not loaded anymore and any user who don't know what we did under the hood would cry my site is broken. Because the script XY is not loaded anymore.

@yvesh and I are currently working on com_csp that would assist site owners to solve the similar problem we have for all remote sites that get called by your site so you can easily whitelist them using the CSP Plugin (and block anything else).

We could try to record there also the current hash to whitelist (and this is not that easy at all given that the browsers handle that reporting stuff different) and on any change on the remote site the site is broken, well this is the expected behavior of that option but still the avarage user don't know what is happening.

For the mention proposal this would also mean we need to bind JDocument/JHttp to the mention database table and this is very bad, we could also write that info as json to a file but i don't think we would be more happy with that.

So conclusion is that we can add support so you as a developer can implement that into your JHttp/JDocument calls and solve the value problem yourself but please understand that implementing that into the extension could result into broken sites that don't update your extension if we would hardcode that value. If you don't hardcode that value and get the hash on any page reload the whole point of that option is gone as you would also validate a broken value. The only way to solve that problem would be some kind of api to get the values for a central server you as extension owner keep up-to-data but IMO this would be big overkill for that kind of issue.

I hope my thoughts are clear? Feel free to ask if not maybe I miss an important part.

perfectly clear.
I didnt think it was part of your plugin but wanted to check to see if this was on your radar to be done in a future version

To be honest, this is damn near impossible to support at the CMS level with too many dynamic moving pieces. Leaving this one for plugin territory.