CSP Requires 'unsafe-inline' for popup style attribute

[codesplode]

Checklist

• I've looked at the documentation to make sure the behavior isn't documented and expected.
• I'm sure this is an issue with Leaflet, not with my app or other dependencies (Angular, Cordova, React, etc.).
• I've searched through the current issues to make sure this hasn't been reported yet.
• I agree to follow the Code of Conduct that this project adheres to.

Steps to reproduce

Using the popup in any leaflet map, the library adds a style attribute to the popup layer causing csp policies without unsafe-inline to report errors. Because this is using the style attribute, there is no other workaround other than allowing unsafe-inline.

More Information

In my tests so far, this style attribute seems to make no visible difference when it is blocked. Perhaps it can be removed if its not a browser compatibility requirement. I'm not using report-only, so I do not believe the css is being evaluated and even if I include the hash chrome suggests in my Content Security Policy the same error still occurs with the same hash, implying it is using the style attribute.

I'm not sure the best way to create a viewable demo since this requires setting a CSP accordingly, but I will provide a test page if I can figure out a good way to do so. Please let me know how I can assist and I'm certainly willing to help test any modification you like.

Expected behavior

That the library has some mechanism for avoiding this error by default or provides a mechanism to do so.

Google Places, for example, will use an empty, nonced, style tag to add any css if one is provided, instead of writing inline styles.

Current behavior

A content security policy without unsafe-inline allowed will fail consistent when a popup is triggered to be displayed. The error does not appear to happen again when it is disabled, but will occur again each time a popup is displayed/added to the map.

Minimal example reproducing the issue

No response

Environment

• Leaflet version: 1.9.4+v1.d15112c
• Browser (with version): Chrome Version 119.0.6045.123 (Official Build) (64-bit)
• OS/Platform (with version): Ubuntu Linux 22.04

[jonkoops]

@codesplode did you check the discussion under #7511? Particularly @Malvoz's comment #7511 (comment), might be of use.

[codesplode]

Thanks @jonkoops ,

Yes, I did attempt to use the unsafe-hashes route as suggested by chrome, but hashes do not work for style attributes which is why I suspect the error continues even with that hash allowed.

For reference, this was the addition that was suggested by Chrome and I tested:
'sha256-qnVkQSG7pWu17hBhIw0kCpfEB3XGvt0mNRa6+uM6OUU='

Chrome and Firefox aren't very specific beyond this hash which style code is causing it and I'm trying to sort that out as well to give you more specifics on exactly the style attribute and element.

[Falke-Design]

We are positioning the popup over inline-style. How should this work without inline?

Leaflet/src/layer/DivOverlay.js

Line 312 in 3d0d4b3

this._container.style.bottom = `${bottom}px`;

[jonkoops]

We are positioning the popup over inline-style. How should this work without inline?

@Falke-Design I think that @codesplode's issue lists an alternative, but I am not sure we'd want to do this:

Google Places, for example, will use an empty, nonced, style tag to add any css if one is provided, instead of writing inline styles.

I guess this is something we could experiment with to see if it would be possible for us to do as well.

[jonkoops]

Adding this to the backlog, since it's probably something we'd like to pick up eventually, but don't have time for now. Also marking this as 'help wanted' so if anyone is willing to pick this feel free to do some experimenting.

[codesplode]

I understand it is definitely an awkward issue and believe that style attributes as well as other attributes for JS for example should have been accounted for in the security standards.

Oddly enough, as I mentioned it does not appear to be hurting the display in our particular instance and the hash is always the same, suggesting it is the exact same css each time that is triggering it (so it is not a positioning issue unless it is always the same position).

To @Falke-Design 's comment, I don't think that is the style causing the issue unless the bottom position is a constant somehow in my use. I suspect the issue is occurring when the style attribute is being used outside of JS or perhaps parsed in innerHTML rather than being set using the js properties as you are doing there. (We have of course nonced / allowed the js).