先找出適合固定的檔案
瀏覽器載入外部程式後，該檔案便能影響整個頁面。若供應商或發佈端點更改同一網址的內容，商店即使沒有部署新版本，也可能收到未經審核的程式碼。子資源完整性（SRI）在 script 或 stylesheet 元素加入核准內容的雜湊值；瀏覽器下載後自行計算，內容不符便拒絕載入。這適合有明確版本、內容穩定的外部檔案。若供應商的網址本來每次都回傳不同內容，而又沒有固定版本，直接套用便可能經常中斷服務。
先列出購買、帳戶及支援流程實際載入的外部網址。每個網址記錄負責人、用途、版本、程式或樣式類別、載入頁面，以及無法載入時的顧客結果。付款元件失敗時需要的處理，與裝飾動畫失敗時不同。負責人要判斷該檔案是否既值得保護，又能穩定到逐位元組核准。SRI 只能核對交付內容與指定雜湊值是否相同；它不會替商店判斷原來核准的程式碼是否安全，也不會判斷供應商應否取得該頁面的權限。
核准版本並計算雜湊值
應選擇不可隨意改寫的版本網址，或由部署流程控制的發佈檔案。取得瀏覽器實際會下載的位元組，按團隊既有依賴項流程核准該版本，再計算 SHA-384 或 SHA-512 的 Base64 雜湊值，連同演算法名稱放進 integrity 屬性。MDN 的實作說明列出瀏覽器核對方式及計算例子。不要因為檔名相同，就從另一個鏡像站複製雜湊值；壓縮方式、換行或供應商重新編譯，都可能令內容不同。指定值必須對應實際交付的檔案。
跨來源載入時，元素須有 crossorigin 屬性，檔案伺服器亦須回應所需的 CORS 標頭。MDN 指出，帶有完整性資料的跨來源請求不能採用一般不透明的 no-cors 模式；即使位元組完全正確，缺少 CORS 配置仍會令檔案載入失敗。因此必須在真實瀏覽器查核回應，不能只在本機算出雜湊值便算完成。若供應商無法提供穩定版本及相容的 CORS 交付，團隊可按授權及更新安排考慮自行託管經審核的副本，或選另一種整合方式。
預先安排檔案被拒後的流程
內容不符時，瀏覽器按設計拒絕執行意外的程式。若它只負責非必要的視覺效果，影響可能有限；若是結帳依賴項，顧客可能無法付款或看不到必填欄位。因此應先設計檔案被拒時的顧客路徑，再啟用固定。頁面可以解釋結帳暫時無法完成、保留購物車，並提供安全重試或聯絡方法；不能默默將訂單標成已付款，也不能催促顧客反覆嘗試扣款。監察時應分清檔案不存在、CORS 失敗及完整性不符，因為三種問題的修復方法不同。
舉一個假設例子：商店把結帳輔助檔案 A 版的雜湊值固定下來，供應商卻在同一網址換成 B 版。舊頁仍記錄 A 版雜湊值，瀏覽器拒絕 B 版，正是預期結果。發佈負責人應檢查 B 版，在測試環境完成購買流程，通過後把版本網址及雜湊值一起更新，再按正常變更程序部署。只為消除瀏覽器錯誤而關掉檢查，會失去原來的保護。若重要流程已受阻，先使用預先安排的回滾或其他付款路徑，再調查原因；不要在壓力下為未審核內容急忙產生新值。
清楚知道控制的界線
SRI 只核對元素指定的外部檔案，並非替該程式往後每個網絡請求作全面審批。即使檔案符合雜湊值，原來程式仍可能有漏洞，或把資料送到商店不希望的地方。能同時改動網頁及 integrity 值的人，亦可能替換整套配對。因此仍需審查供應商、限制頁面暴露的資料、在可行時使用合適的內容安全政策，並維持依賴項更新流程。完整性值只是供應鏈決策的一層控制，不能取代整體判斷。
外部 CSS 也應納入同一份清單。樣式表雖然不如 JavaScript 直接執行程式，意外改動仍可遮住警告、改變表格佈局，令顧客看不清必要選項。若版本穩定且團隊能維護更新週期，就可固定該樣式表，並確認它依賴的其他資源仍正常載入。不要以為固定頂層樣式表，就等於證明其中引用的每張圖片或字體都未變。應按顧客需要理解哪些內容來判斷關鍵資源，並在每次核准更新後測試完整畫面與操作。
安排不會突然中斷的發佈
先在與正式環境使用相同 CDN 回應路徑的測試環境驗證。確認預期程式及樣式能載入，再刻意提供不同位元組作故障測試，觀察瀏覽器是否拒絕，顧客退路是否出現。要在商店支援的瀏覽器檢查控制台及網絡資訊，辨別 CORS 與雜湊錯誤。可行時先在有限頁面推出，觀察結帳錯誤、檔案載入錯誤及顧客報告。若考慮使用 Integrity-Policy 標頭，MDN 提及可先採用只報告模式，找出缺少完整性資料的資源，再決定是否阻擋；也要實測瀏覽器支援和報告流程。
應寫明誰有權核准新雜湊值。一般程式庫更新會改變檔案，因此必須有新值；變更記錄應連結已審核版本、實際檔案網址、計算所得雜湊值及顧客流程測試。回滾安排要同時恢復已知可用的檔案與相配的頁面標記，不能只回滾其中一半。若供應商毫無預告地改寫沒有版本的網址，雜湊不符正好顯示這種交付方式不適合核准流程。應要求有版本的檔案，或選擇商店能夠明確驗證及維護的整合方式。
以真實顧客流程驗收
可用正式環境相近的來源載入已核准版本，從商品頁走到購物車及結帳，逐一確認必要控制項與外部元件。再換上雜湊不符的檔案，確認頁面不會假裝付款已成功；移除所需 CORS 許可，確定團隊能辨認故障。最後把依賴項升級至已審核版本，再回滾至上一組已知可用的檔案與標記。這些測試證明完整性檢查與復原方法能一起運作，而不只是 HTML 裏多了一段雜湊字串。
負責人最後可問三個問題：供應商能否提供穩定、可審核的檔案？團隊每次有意更新檔案時，能否同步維護雜湊值？瀏覽器拒絕檔案時，顧客能否明白發生甚麼事及下一步？若其中一項是否定，先改善交付安排或退路，才固定關鍵依賴項。若三項都有答案，就記錄確切檔案並測試故障路徑。SRI 的價值，是拒絕未經核准的變更，同時保留商店有計劃地推出新版本的能力。
為依賴項指定負責人與退出方法
每個被固定的外部檔案都應有一名負責人，另設可在供應商發佈安全更新時接手的同事。負責人要知道檔案在哪些頁面載入、雜湊值如何計算、哪個版本能證明位元組來源，以及檔案被拒時哪段顧客流程會受影響。這些資料應放在部署設定附近，避免緊急處理時只能依靠某人在舊對話裏的記憶。若供應商停止支援某版本，不能因雜湊值仍相符便無限期沿用；應安排審核替代版本，再測試相關流程。
供應商改變交付方式時，退出方法尤其重要。若不再提供固定內容或相容的跨來源標頭，應評估可否在授權容許下本地託管、改用另一供應商，或移除該功能。每條路都有業務成本：本地副本需要有人持續更新；更換供應商要重新測試整合與無障礙操作；移除功能可能改變對顧客的承諾。應在下次故障前寫明選擇。SRI 會以拒絕載入的方式揭示未經計劃的變動，但團隊仍須有預先核准、能繼續服務顧客的方法。
進行前先確認
- 外部網址是否有版本而且內容穩定？
- 跨來源交付能否通過 CORS 和完整性檢查？
- 顧客故障退路及回滾方法是否已測試？
