Subject: Inquiry Regarding Subresource Integrity (SRI) Support and CORS Headers
I am writing to inquire about the support for Subresource Integrity (SRI) in your services. Specifically, I would like to know if you provide endpoints or resources to retrieve integrity hashes for your scripts.
In an attempt to implement SRI, I generated hashes locally for your scripts. However, I encountered an issue where the scripts are blocked due to the absence of the appropriate ‘Access-Control-Allow-Origin’ header in the response. This suggests that the necessary CORS headers are not being sent.
Could you please provide guidance on enabling SRI for your scripts and advise on configuring the correct CORS headers to facilitate this?
Hello,
Thank you for reaching out and for your patience.
You are correct that our scripts served through sdk.woosmap.com currently do not include the Access-Control-Allow-Origin header, which is necessary for enabling Subresource Integrity (SRI).
We are working on updating our configuration to include the appropriate CORS headers, specifically the Access-Control-Allow-Origin header.
I will keep you informed as soon as this update is implemented. Thank you for bringing this to our attention, and please feel free to reach out if you have any further questions or concerns.
Could you provide a clear timeline for when the update to include CORS headers will be implemented? This is an important issue for us, and knowing the expected timeframe is essential to ensure proper integration on our side.
We are currently working on the update to include CORS headers. While I cannot provide an exact release date, we expect the support to be available within the next few days, possibly a bit longer. I will notify you here once it is completed.
Regarding the evolving nature of our JS Scripts files, relying on a single hash indefinitely is not recommended. How do you plan to handle this? Will you generate the hash on the fly and cache it somewhere? If we release a new script, your existing hash will become invalid and raise an SRI error for your users. Just wanted to highlight this.
I appreciate you bringing this up. Our plan is to generate a hash locally and include it in the script’s integrity attribute. This relies on the assumption that the version is embedded in the script’s name. If updates occur, we expect the version in the script name to be incremented, ensuring our script remains functional without breaking.
Can you confirm if this approach will work? Specifically:
Do you ever update the script body without bumping the version in the script name?
Do you provide an endpoint for retrieving the current hash?
Alternatively, is there another mechanism you can offer to ensure integrity?
At this time, we do not plan to provide an endpoint for retrieving the SRI hash. When we release an update, it replaces the current version without changing the name. An alternative solution could be to use the Last-Modified header to ensure the integrity of the script.
When fetching the script, you can check the Last-Modified header to determine if the script has been updated. If the Last-Modified date has changed, you can generate a new hash for the script and update your integrity attribute accordingly.
Does this solution sound good to you?
This means we should generate the hash on the client side during runtime. The CI/CD process won’t suffice because the script might change between releases of our app, correct?
Using the Last-Modified header could be a viable solution, but it raises another question: where should this date be stored, and would it be secure enough?
We have pushed an updated configuration, so CORS headers are now correctly set for script files.
Regarding your implementation, I’m sorry, but I don’t see a strong solution other than hosting the JavaScript file on your own server and computing the hash through your CI/CD pipeline before deployment. This approach would also require you to frequently update the script to benefit from the latest modifications in the SDK.
Using the Last-Modified header is more of a workaround and would ultimately also require you to have a dedicated endpoint on your side to generate the new hash dynamically. While it could help your CI process determine if a new hash needs to be generated, it won’t be helpful for generating the hash on the client side, as this would go against the purpose of SRI.
