Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide Subresource Integrity for Web Resources #1983

Open
EugenFischer opened this issue Oct 28, 2024 · 10 comments
Open

Provide Subresource Integrity for Web Resources #1983

EugenFischer opened this issue Oct 28, 2024 · 10 comments

Comments

@EugenFischer
Copy link

From my point of view, support for SRI for web resources would be necessary.

OmniFaces has a powerful way to handle web resources with CombinedResourceHandler.
But you have to make do with many exceptions and restrictions.

From a security point of view, it would make sense to equip the web resources with SRI out of the box.

What do you think, would such an extension be useful and feasible?

Many greetings

@melloware
Copy link

@EugenFischer so you want the SRI on every JSF resource produced with h:output script? Correct?

@EugenFischer
Copy link
Author

@melloware, yep, on script and style resources

@BalusC
Copy link
Member

BalusC commented Nov 2, 2024

You mean, the framework must auto generate the integrity (and probably crossorigin) attribute like OmniFaces CombinedResourceHandler does? Point taken, but for sake of clarity, you could for the time being manually set it as a passthrough attribute:

<... xmlns:a="jakarta.faces.passthrough">
    ...
    <h:outputScript library="jakarta.faces" name="faces.js" a:integrity="sha384-xxxxxxxxxxxxxxx" />

@BalusC
Copy link
Member

BalusC commented Nov 6, 2024

I approve this proposal btw.

@tandraschko, WDYT? Candidate for 5.0? The W3C spec is currently still in draft mode but it could be final before close of 5.0.

@tandraschko
Copy link

what should the JSF impl do?
Just render the integrity attribute, if not defined by the user? ad adding crossorigin=anonymous?

I wonder whats the benefit as our resource urls are all relativ to the current host?
the first liks mostly talk about CDN.

@BalusC
Copy link
Member

BalusC commented Nov 7, 2024

Right. This makes only sense for CDN resources.

@tandraschko
Copy link

@BalusC
Copy link
Member

BalusC commented Nov 8, 2024

Nope, I just didn't think through it. It makes indeed no sense for local web resources. On the other hand, h:outputScript/h:outputStylesheet have no support for CDN resources so it wouldn't be possible to use them for CDN resources in first place.

@EugenFischer Did you have local or CDN resources in mind while opening this issue? Was you referring to OmniFaces CDNResource helper class in the statement "but you have to make do with many exceptions and restrictions"? Which problem exactly, ultimately, was you trying to solve which made you to come up with this issue?

@EugenFischer
Copy link
Author

EugenFischer commented Nov 14, 2024

@BalusC
i wanted to use it for local web resources.
i saw that you had also calculated an SRI for the collected javascrits / styles in the CombinedResourceHandler.
i don't know if this is a smart idea, but i wanted to make sure that no outdated (cached by some proxy) or truncated resources arrive at the client. (because we are currently trying to solve just such a problem)
CombinedResourceHandler is an awesome and powerful tool, but the combining makes it very difficult to check if all necessary resources arrive in the expected version.

@BalusC
Copy link
Member

BalusC commented Nov 14, 2024

but i wanted to make sure that no outdated (cached by some proxy)

Just add VersionedResourceHandler.

or truncated resources arrive at the client

Entire combined resource returns 404 if that is the case so just check for response status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants