頁面看起來正常，不代表沒有問題
一個電商店面可以載入很快、商品齊全、結帳流程順暢，但底層的 JavaScript 正在做店主從未授權的事：抽走聯盟佣金、劫持搜尋與點擊、竄改分析數據，或向遠端伺服器詢問下一步要執行什麼。Cloudflare 在 2026 年 9 月 16 日發布的文章裡，把這個盲點講得很清楚：頁面健康與程式碼安全是兩件事。
這篇貼文追蹤了四個實際營運中的惡意行動、共八個 payload，全部由 Page Shield ML 自動偵測，人類只在系統標記後才進場覆核。事後用一般安全掃描工具回頭檢查，八個 payload 有七個完全不在 VirusTotal 上，URLScan 也沒有對任何一個給出惡意判定。這個對比是整篇的核心：等到威脅情報資料庫替你貼上標籤，你已經晚了。
為什麼簽章式防禦在這裡失效
四個行動沒有共用簽章，也沒有共通的藏匿手法。Cloudflare 描述其中一個會等到裝置、國家、時間、referrer 或瀏覽器狀態符合條件才醒來；另一個把無點擊的聯盟請求塞進不可見的 iframe；還有攔截點擊、壓制監控、或條件式從遠端載入更多程式碼的變體。
換句話說，靜態掃描一次頁面是不夠的。這些腳本被設計成在正確的受害者出現前保持安靜，所以需要的是持續的瀏覽器可視性，而不是單點檢查。
Cloudflare 的做法是把 JavaScript 當成圖來推理，而不是一段平面文字。同一個 GNN 先前已經抓過惡意 npm 套件與一個實際運作中的 Magecart 付款側錄程式；它透過語法樹連結程式符號，看出誰呼叫誰、攻擊者埋了什麼、還有什麼仍在對外連線。被 GNN 標為惡意的流量不到全部分析量的 0.3%，這些會再送進 Workers AI 上的輕量 LLM 做即時第二意見，以壓低誤判同時維持召回率。
最複雜的腳本則交給一組前沿模型（Cloudflare 稱之為 teachers）各自在獨立 session 中分析，必要時用受限的 JavaScript 評估器拆解片段。模型之間的分歧被當成訊號而非雜訊，每個標記依模型在 Artificial Analysis Intelligence Index 的分數加權投票，形成 benign、payment skimming、other malware、cryptomining 四類的機率分布。只有被標為惡意或缺乏三分之二多數的腳本才需要人工檢視。
四個行動各自偷走不同的東西
第一個行動針對行動裝置訪客：攔截商品點擊後，用新分頁開啟攻擊者預選的商品頁，同時讓原分頁繞經攻擊者的聯盟追蹤連結再回到商店，把歸因 cookie 種在背景。店家可能付出一筆不該付的佣金，更麻煩的是，真正帶來轉介的合作夥伴被搶走歸因，信任一旦破裂，傷害會超過單筆佣金。這個行動的變體用 MutationObserver 監看動態出現的商品磚與按鈕，並在 localStorage 寫入三天冷卻期；被擷取到的暫停版本甚至留有版本註解，記錄自己在 Black Friday 之後被暫停。
第二個行動連點擊都不需要。訪客打開訂房頁、瀏覽選項、完全沒碰廣告，腳本可能已經送出聯盟請求，讓之後的成交看起來像別人轉介的。Cloudflare 指出，程式碼證明了隱蔽的自動化聯盟請求存在，但某個具體請求是否真的完成歸因、入帳或付出佣金，並未被觀察到。這裡的界線值得產品團隊記住：能證明機制，不等於能證明損失金額。
供應鏈與 typosquatting 才是入口
第一個行動的投放路徑經過兩個看起來很普通的 tag manager：Google Tag Manager → 另一個 tag manager → 惡意腳本。Cloudflare 明確說明，這是 payload 抵達瀏覽器的方式，不是任一 tag manager 被入侵的證據。
更值得留意的是網域偽裝。其中一個投放主機 adtargett[.]com 與 1998 年註冊的廣告網域 adtarget[.]com 只差一個 t，首頁還自稱 Performance Marketing Agency。這種 typosquatting 讓它混在例行行銷標籤裡，通過快速的人工審查。
對產品與行銷團隊來說，實務上的下一步不是買更多掃描器，而是承認第三方腳本是一條持續變動的攻擊面。Cloudflare 的案例顯示，偵測能力必須跟著程式碼的執行時行為走；而對一般開發者，這也呼應了我們先前談過的 Cloudflare 把混合用途爬蟲拆成三種行為 那類思路：先分清誰在做什麼，再決定要不要放行。
至於這套 ML 流程本身，Cloudflare 說回饋迴路仍有一部分靠人工，正在開始自動化。這是個誠實的限制，也提醒我們：自動偵測的準確度不是一次性設定，而是需要持續維護的系統。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。