[VibeCoding] 'integrity' attribute Error Resolve
table of contents
It's been a while.
Sujun from the Systems Development Department is becoming more and more like an AI man within the company. To
put it simply, I'm sharing an error that occurred while using AI to VibeCoding.
One day, CSS and JS stopped loading.
The Chrome extension mentioned in a separate article is based on AI and VibeCoding, but
when I tried to import the changes on a PC that is different from the PC I normally develop and check the operation, I found that some CSS and JS were not loaded.
I was very confused as to the phenomenon that the source had not been changed and that it was displayed normally on the development PC.
Actual error contents
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 for the error, but I couldn't find any information that could help resolve my situation.
The best way to get the problem is to ask the implementer.
I asked AI. Apparently it's happening with the code below.
<link href="../lib/bootstrap.min.css" rel="stylesheet" integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM" crossorigin="anonymous">
this
integrity
Apparently the cause is. I was told about this.
What is the integrity attribute?
The integrity attribute appears to be used to verify the integrity of a resource that has not been tampered with.
By assigning the resource's hash value as an attribute, check whether there is a difference between the resource's hash value obtained by the browser and the hash value set in the integrity attribute.
Identifying and resolving the cause of occurrence
This time I followed the steps below to resolve the issue.
I compared the source code comparison- filtered
file is transferred between servers or PCs, the content when the browser loads is different due to "differences in encoding." - Checking the encoding
When I checked the encoding of each file, I confirmed that the development PC was LF and the other PC was CRLF. - Checking for corrections
As a response to the corrections, we have confirmed that the data is loaded correctly by changing the other PC to LF.
Bonus: Generating hash
The following commands can generate a hash value for the specified file:
please also refer to the MDN subresource completeness
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A
In my environment, the above command did not give the intended hash value, but I was able to create it with the command below.
// Regular version $fileContent = Get-Content -Path File Path -Encoding Byte $hash = [System.Security.Cryptography.SHA384]::Create().ComputeHash($fileContent) [Convert]::ToBase64String($hash) 9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM // 1 line version [Convert]::ToBase64String([System.Security.Cryptography.SHA384]::Create().ComputeHash([System.IO.File]::ReadAllBytes("FilePath")) 9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM
summary
From this case, we learned the following points:
- The existence of resource verification function using the integrity attribute.
- Even for resources with the same content, differences in encoding (CRLF vs LF) affect hash values
- Small differences in settings can lead to big errors, so you need to pay attention to differences between environments
VibeCoding is a lot of fun, but there are some problems like this one that are difficult to solve with AI support alone. It was a great opportunity to reaffirm the importance of basic knowledge.
I hope this article has been of help to you!