[VibeCoding] Fixing the 'integrity' attribute error

table of contents
It's been a while.
I'm Sujun from the System Development Department, and I'm quickly becoming something of an AI guru within the company.
I'd like to briefly share with you the error I encountered while VibeCoding using AI.
One day, CSS and JS stopped loading
The Chrome extension I mentioned in another article uses AI and VibeCoding, but
when I tried to import the changes and check that it worked on a PC other than the one I normally use for development, I encountered an issue where some of the CSS and JS were not loading.
I was very confused because I hadn't made any changes to the source and it was displaying normally on my development PC
The actual error
Failed to find a valid digest in the 'integrity' attribute for resource 'chrome-extension://pnknjjpncnciijkpdfgfiikmhlmamaid/src/lib/bootstrap.min.css' with computed SHA-384 integrity 'kKU3+OPzehmYTvkHC2v4pQedEFsYRKntOejtb44v+QUK8+Z3UBoSur+7Q3tDF4Rn'. The resource has been blocked.
I did a Google search on the error, but I couldn't find any information that would help me solve my problem
The best way to find out about problems is to ask the implementer
I asked the AI, and it seems to be happening with the following code:
<link href="../lib/bootstrap.min.css" rel="stylesheet" integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM" crossorigin="anonymous">
this
integrity
This seems to be the cause. I was told about this
What is the integrity attribute?
The integrity attribute appears to be used to verify the integrity of a resource to ensure it has not been tampered with.
By assigning the resource's hash value as an attribute, the browser checks whether there is a difference between the hash value of the resource retrieved by the browser and the hash value set in the integrity attribute.
Identifying the cause of the problem and the process for resolving it
This time I was able to solve the problem by following the steps below
- the source code
, but no differences were found. - Narrowing down the cause:
We hypothesized that when files are transferred between servers or PCs, the content is read differently by the browser due to "differences in encoding." - Checking the encoding
When I checked the encoding of each file, I found that it was LF on the development PC and CRLF on another PC. - Confirming the fix
As a workaround, we confirmed that the file could be read correctly by changing the other PC to LF.
Bonus: Hash Generation
You can generate a hash value for a specified file using the following command.
For more information, see the MDN page on subresource integrity
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A
In my environment, the above command did not produce the intended hash value, but I was able to create it using the command below
// Standard version $fileContent = Get-Content -Path file_path -Encoding Byte $hash = [System.Security.Cryptography.SHA384]::Create().ComputeHash($fileContent) [Convert]::ToBase64String($hash) 9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM // One-line version [Convert]::ToBase64String([System.Security.Cryptography.SHA384]::Create().ComputeHash([System.IO.File]::ReadAllBytes("file_path"))) 9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM
summary
The following points were learned from this case:
- The existence of resource validation functionality using the integrity attribute
- Even for resources with the same content, differences in encoding (CRLF vs. LF) affect the hash value
- Small configuration differences can lead to big errors, so pay attention to differences between environments
VibeCoding is a lot of fun, but there are also problems like this one that are difficult to solve with AI assistance alone. It was a good opportunity to reaffirm the importance of basic knowledge. I
hope this article was helpful to you!
5