公共CDN腳本風險

今天看到黑暗執行緒大大寫了一篇 CDN 相關的貼文，講了一下引用第三方公共 CDN 檔案的優缺點，而貼文底下也有不少回應補充（我也去補充了一下XD），由於這個議題很有趣，因此這邊再簡單講一下我的想法。

先說明一下，這篇提的情境是在網頁上引用來自於 unpkg 或是 cdnjs 等等這種第三方公共 CDN 的 JavaScript ，你對內容沒有掌控權，只能使用不能修改，跟自己把東西放到 CDN 是完全不同的情境。

我的想法是，除非是壞掉也沒關係的小玩具，否則一律建議不要。

使用那些公開免費的 CDN，最大的優點就是方便，直接 script 無腦引入就好，而且通常速度比放自己那裡快（假設自己那裡沒有開 CDN 的話）。

缺點的話主要就兩個，一個是那些第三方網站掛掉你的網站就跟著掛了，第二個是資安風險，你引用的那些來源被入侵你的網站也跟著被入侵，就是俗稱的供應鏈攻擊。

這些問題其實實際上也發生過不少次。例如說 2023 年 12 月我就寫過冷錢包公司 Ledger 的 CDN 被入侵的事件；還有去年 6 月才發生的 polyfill 事件，都是直接使用其他人 host 的腳本而導致資安問題的經典案例。

就連 Cloudflare 自己經營的 cdnjs 也曾經被打進去過，說明了這些第三方 CDN 的安全性可能沒有你我想像中的高。就算前端用了 integrity 防禦，當攻擊發生時，仍然會面臨兩個問題，第一個是網站會掛掉（因為檢查不通過），第二個則是如果那些腳本原本就是動態再引用其他網址，那 integrity 是無效的，因為腳本中的文字沒有變，而是引用的來源內容變了。

再者，以往使用這些第三方 CDN 的好處是因為快取的關係，別的網站用了你也能受益，只要下載一次就好。但自從 Chrome 在 2020 年開啟了快取分區（cache partition）的功能後，這點也不再成立。

總之呢，前端直接引用那些第三方 CDN 的 JavaScript，就是拿方便性來換取安全性跟穩定性。如同我開頭所說，如果是掛掉也沒差的小玩具我覺得倒是無妨，頂多一年掛個一次。

但若是公司的服務用了結果出事，那影響就比較大了，畢竟這個風險是完全可以避免的。

不過話說回來，其實整個議題與 CDN 這個技術沒什麼關係，本質上就是個「動態引入其他網站的腳本」的問題，當內容不可控而且是動態的時候，自然而然就會提高風險。

延伸可以參考我在《Beyond XSS》裡關於快取風險的章節，以及我之前寫過的 polyfill.io 事件。書籍版本也可以在天瓏找到。