[VibeCoding] Fixing the 'integrity' attribute error

It's been a while.
This is Sujun from the Systems Development Department, who's becoming something of an "AI guy" within the company.
I'd like to briefly share an error that occurred while I was using AI for VibeCoding.

One day, CSS and JS stopped loading

I described in another articleThe Chrome extensionuses AI and VibeCoding, but
when I tried to implement the changes and test its functionality on a different PC than the one I normally use for development, I encountered a problem where some CSS and JS files 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 and ensure it hasn't been tampered with.
By assigning the resource's hash value as an attribute, the browser checks if there is any discrepancy between the hash value of the resource it retrieves 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

1. the source code
   itself, but no differences were found.
2. To narrow down the cause
   , we hypothesized that when files are transferred between servers and PCs, "encoding differences" cause the browser to read them differently.
3. Encoding Check:
   Upon checking the encoding of each file, I confirmed that the development PC used LF encoding, while the other PC used CRLF encoding.
4. the correction verification
   process, we confirmed that the file could be read correctly by changing the encoding on another PC to LF.

Bonus: Hash Generation

The following command can generate the hash value of a specified file.
the MDN sub-resource integrity please refer to

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 as this case shows, there are problems that are difficult to solve with AI assistance alone. This was a good opportunity to reaffirm the importance of fundamental knowledge. I
hope this article was helpful to you all!