多數人以為信用卡在網路上被盜刷，是因為連上了假冒的釣魚網站，或是自己沒看清楚網址列。但更棘手的情況是，受害者用的就是正確、一個字都沒拼錯的網址，結帳頁一如往常跑完整個流程，訂單確認信也準時寄到信箱，卡號卻早已在按下「送出訂單」的那一刻，被複製了一份送到別人手上。
這種攻擊有個專有名稱叫 Magecart，也稱作 web skimming 或 e-skimming，指的是一段被偷偷植入結帳頁的惡意程式碼，趁使用者輸入卡號、姓名、地址的當下就把資料側錄下來，跟伺服器有沒有被入侵、資料庫有沒有整批被偷走完全是兩回事。這個名字最早專指鎖定 Magento 商店的攻擊者，後來演變成統稱所有平台上同類攻擊的說法，如果你的網站是用 WordPress 架設的網路商店，一樣可能中招。看懂它繞過了哪些防線、又是怎麼躲開巡查，才知道防護資源該放在哪裡。
先從這個看起來一切正常的結帳頁，怎麼在正常運作的同時洩漏卡號講起。
Magecart 是什麼？結帳頁正常運作也可能已經外洩卡號
cside（國際商用用戶端資安平台）對 Magecart 的定義相當明確，這是一種瀏覽器端的網頁側錄攻擊，攻擊者把惡意 JavaScript 植入合法網站，通常是結帳頁或登入頁，在使用者輸入的當下擷取信用卡資料、帳密或個人資料。這個名字的由來要回到 2015 年到 2016 年間，資安研究者發現大量用 Magento 架設的網路商店被植入側錄程式，「Mage」取自 Magento、「cart」取自購物車，兩個字拼在一起就成了這種攻擊的代稱。
只是這個名字後來早就脫離了 Magento 本身。隨著同一套手法被複製到各種架站系統，Magecart 逐漸變成這類瀏覽器端側錄攻擊的通稱，不再限定平台。SOCRadar（國際商用資安情報平台）對 e-skimming 的定義補上了另一個重點，使用者輸入的資料會被瀏覽器直接送往攻擊者，而合法的交易流程仍可能正常繼續進行。換句話說，用 WordPress 搭配 WooCommerce 架站，或是用 Shopify、自架系統，都在同一個風險範圍裡，不是只有 Magento 才要擔心。Silent Push（國際商用威脅情報公司）對這種攻擊的描述也點出同一個核心，整段側錄過程發生在客戶端，對使用者和網站經營者來說幾乎不會留下痕跡。
之所以說這是瀏覽器端攻擊，是因為它跟一般認知的「網站被駭」不是同一件事。伺服器沒有被入侵，資料庫也沒有整批外洩，攻擊者要的是使用者打字當下的原始資料，卡號、有效期限、安全碼之外，姓名、地址、電話這些表單欄位也會一併被複製。這也是這種攻擊格外難防的原因，防禦重心多半放在伺服器端，而 Magecart 打的正是這個死角。
偽造付款表單疊在結帳頁的真實欄位上方側錄輸入
Silent Push 在 2026 年 1 月發布的技術報告，完整還原了一起鎖定 WordPress 加 WooCommerce 加 Stripe 網站的長期側錄行動，不是理論推演，而是真實發生、且持續多年的案例。這起行動至少從 2022 年初持續至今，鎖定的發卡組織涵蓋 American Express、Diners Club、Discover、JCB、Mastercard、UnionPay 六個主要品牌，藏在網站裡的惡意程式碼約有 600 行，經過刻意混淆，不容易一眼看穿。
惡意程式碼混進頁面的手法，是偽裝成 Facebook 的像素追蹤腳本 fbevents.js，這是多數結帳頁本來就會載入的行銷追蹤元件，不容易引起懷疑。程式碼會先按兵不動，等到真正的 Stripe 付款表單載入完成，才把這個真表單用顯示屬性設為隱藏，另外用 iframe 生成一個外觀幾可亂真的假表單。這個假表單不只長得像，欄位、卡別辨識（自動判斷 Mastercard、JCB、Amex 等）都做得跟真表單一樣，連即時格式化與輸入錯誤的紅框提示都一併模仿，讓使用者更不容易起疑。
從使用者開始打字的那一刻，卡號、到期日、安全碼、姓名、地址、電話這幾個欄位就已經被即時記錄下來，不必等到按下送出鍵。按下「送出訂單」的瞬間，側錄程式會把蒐集到的資料整理成 JSON 格式，用固定金鑰做 XOR 加密再轉成 Base64 編碼，透過 POST 請求送往攻擊者的伺服器。資料送出之後，程式會清掉那個假表單、把真正的 Stripe 表單恢復顯示，還會自動幫使用者點一次真正的付款按鈕。
多數受害者這時只會看到一次「付款失敗」的錯誤訊息，其實那只是假表單自己的驗證邏輯在跑，跟真正的交易無關。使用者以為自己打錯了資料，重新輸入一次，第二次通常就順利成功，完全不會意識到資料早已經在第一次輸入的當下外洩。cside 把這整套流程拆成四個通用步驟：注入、讀取表單資料、側錄外送、維持交易正常完成，並補充側錄外送常見走 fetch、XMLHttpRequest 或隱藏的圖片請求，因為走的是正常的 HTTPS 連線、封包也很小，不會觸發警示；就算外送失敗，程式也會直接吞掉錯誤，不影響正常交易進行。
側錄程式碼刻意避開管理員帳號的偵測視線
上一節講的是這種攻擊怎麼發生，這一節要問的是另一個問題，為什麼經營者自己巡站，往往也看不出任何異常。答案藏在側錄程式的設計裡，它從一開始就把避開管理員發現這件事，當成核心邏輯的一部分。
以 Silent Push 追蹤的那起 WordPress 攻擊為例，程式碼會先檢查頁面上有沒有 wpadminbar 這個元素，也就是只有登入 WordPress 後台的使用者才會看到的管理列。一旦偵測到，整段惡意程式碼會自我移除、停止監看，用自己的帳號檢查網站的人，看到的永遠是正常畫面。cside 對同一個現象的解釋更直接，多數資安工具是為了保護伺服器端活動而設計，WAF 檢查的是進出應用程式的流量，看不到瀏覽器直接送給其他網域的請求。
對帳與詐欺分析工具同樣抓不到破綻，因為真正的付款流程照樣完整跑完，訂單成立、出貨照常進行，財務數字完全正常。cside 也點出這種攻擊最傷人的地方之一，它很少被真正遭入侵的那家企業自己發現，多數案例最先察覺異常的，反而是發卡銀行或持卡人本人。等到外部通報回到店家手上，側錄程式往往已經默默運作了數週甚至數月。
英國航空信用卡外洩案，二十二行程式碼換來鉅額罰款
側錄行動被發現得多晚，代價通常就有多大，英國航空（British Airways）2018 年的資料外洩事件，是目前資訊揭露最完整的案例之一。攻擊者只用了約 22 行惡意 JavaScript，就在英航的付款頁面上即時側錄了約 38 萬至 43 萬名旅客的完整卡號與個人資料，不同階段的統計數字略有出入，正式數字以英國資訊專員辦公室（Information Commissioner’s Office，簡稱 ICO）的裁罰書為準。
攻擊發生在 2018 年 8 月 21 日到 9 月 5 日之間，ICO 調查後還發現另一個問題，英航把包含安全碼在內的完整卡號明碼記錄了下來，原因是一項測試功能上線後忘了關閉，並非刻意設計，而且系統原本就具備的多因素驗證機制也沒有落實。ICO 認定這些疏失違反了 GDPR 第 5（1）（f） 條與第 32 條，也就是資料安全原則與處理安全性義務的要求。
ICO 在 2019 年 7 月一度預告要開出約 1.834 億英鎊的罰單，等於是當時 GDPR 史上最高額度的個資裁罰之一。最終在 2020 年 10 月正式裁罰時，金額大幅調降到 2000 萬英鎊，大約只剩原本預告金額的一成，調降的原因包括英航事後強化了資安措施，以及當時航空業正受到疫情嚴重衝擊。即便調降幅度不小，2000 萬英鎊仍是 ICO 當時開出過的最高罰單，只用了 22 行程式碼換來的代價，遠遠超過大多數電商經營者的想像。
同樣的手法也反覆出現在不同規模的知名電商身上，不是單一個案。cside 的整理提到，Ticketmaster 在 2018 年透過第三方廠商 Inbenta Technologies 提供的聊天機器人腳本被植入側錄程式，這支腳本在每個頁面載入時都會執行，導致約 940 萬名顧客的付款與個資外洩，事發到被發現歷時 4 個月，事後也引來監理裁罰與集體訴訟。Newegg 在 2019 年則是結帳按鈕本身被植入側錄程式，資料被送往一個偽裝成分析服務的網域，外洩超過 1 個月才被發現。
結帳頁疊了最多第三方腳本也最容易被鎖定
從這幾起案例可以看出一個共通點，側錄程式混進來的管道，往往不是店家自己寫的付款邏輯，而是結帳頁上一堆跟收單無關的其他腳本。如果你的網站是用 WordPress、WooCommerce 架設，又仰賴大量外掛擴充功能，這個風險特別貼身。
結帳頁看似只該處理付款，實際上同時還在跑行銷追蹤的廣告像素、GA、再行銷標籤，也常常掛著線上客服工具、商品評論或信任徽章外掛。這些跟收單完全無關的第三方腳本，一樣有機會讀到同一個 DOM 裡的卡號欄位，每多一支腳本，就多一個可能被注入或被入侵的破口。
cside 把攻擊者接觸這些腳本的管道整理成兩大類。第一類是透過 CMS 或電商平台本身，像是過期的外掛或擴充套件、範本或 JS 檔案被不安全地修改、管理員帳號防護不足，攻擊者只要能改動結帳頁的一個 JS 檔案就能植入側錄。第二類是透過第三方程式碼供應鏈，例如標籤管理工具或外部客服外掛的程式碼，可能在全站各頁面（包含結帳頁）都會被載入，即使在那個頁面根本沒有實際功能，一旦這類帳號被入侵、被加入夾帶側錄程式的標籤，所有掛同一個容器的網站結帳頁會同時中招。SOCRadar 對 e-skimming 常見攻擊型態的分類，也把直接入侵商家結帳程式、第三方腳本或供應鏈注入、偽造付款表單與結帳覆蓋層、標籤管理工具或管理帳號濫用並列，跟這個分類互相印證。
腳本越多、維護越鬆散，暴露面就越大，這也是為什麼結帳頁的防護要從限制腳本能做什麼開始談起。
內容安全政策限制結帳頁只能載入受信任網域的腳本
內容安全政策（Content Security Policy，簡稱 CSP）是瀏覽器端的一道白名單機制，結帳頁只被允許執行事先核准來源的程式碼，不在名單上的來源會直接被瀏覽器擋下，不會被執行。對應到 Magecart 的攻擊鏈，CSP 剛好擋住了注入與外送這兩個關鍵動作。
script-src 這個指令決定結帳頁只能從白名單網域載入 JavaScript，陌生來源的腳本會被直接擋下。connect-src 這個指令則決定頁面上的程式碼可以把資料送去哪些網域，就算真的有惡意腳本混了進來，也可能因為送不出資料而失去作用。cside 的說明把這兩個指令的分工講得很清楚，script-src 應該限制在可信任的網域，connect-src 只該放行結帳流程真正需要的端點，而不是放行所有目的地。
CSP 還有一個經常被忽略的附加價值，違規事件是可以回報記錄的，等於多一層偵測陌生腳本或陌生網址是否出現在結帳頁上的手段，一旦有腳本嘗試從不在名單上的來源載入，或是嘗試把資料送到陌生網域，都會留下紀錄。Imperva（國際商用資安廠商）也把導入 CSP 列為建議清單的一項，認為它能為結帳頁多提供一層對抗跨站腳本攻擊與程式碼注入的保護。PCI Security Standards Council（官方產業標準組織）在 2025 年 3 月發布的補充指引，也把 CSP 列為落實 PCI DSS 第 6.4.3 項與第 11.6.1 項要求的技術手段之一。
只是 CSP 不是萬靈丹。如果攻擊者竄改的是一支原本就在白名單裡、被授權執行的腳本，CSP 本身擋不住，這正是前面提到的供應鏈攻擊型態，分析工具、標籤管理器這類腳本常常變動，很難用固定的雜湊值釘死，也因此成為進階攻擊者鎖定的目標。這也是為什麼光靠 CSP 還不夠，得搭配盤點與精簡結帳頁上的腳本一起做。
結帳頁的外掛與腳本清單，多數電商從沒盤點過
多數電商從沒有完整列過結帳頁實際跑了哪些腳本、各自是誰家的、為什麼需要它，這件事本身已經是 PCI DSS 最新版明文要求的項目，也是縮小暴露面最直接的做法。
PCI DSS 第 6.4.3 項要求商家對所有在顧客瀏覽器執行的付款頁面腳本建立清單，寫明每一支存在的理由並取得授權，範圍涵蓋第一方腳本、第三方腳本，以及透過 iframe 載入的內容。Feroot（國際商用資安平台）對這項要求的整理很直接，就是你必須知道並且能說明每一支付款頁面腳本存在的理由。這項要求已經在 2025 年 3 月 31 日起由建議轉為強制，不再是可以緩一緩的最佳實務。
具體做法是，你可以先把結帳頁會載入的每一支腳本都列出來，外掛啟用清單、佈景主題內嵌的追蹤碼、標籤管理器裡的每一個標籤，都標明用途，並判斷是不是真的需要在這一頁執行。盤點完之後，能砍就砍，行銷像素、A/B 測試工具、線上客服、商品評論外掛，這些對完成付款來說都不是必要的，優先從結帳頁移除，或是延後到付款完成頁才載入。cside 的建議更進一步，理想狀況是把結帳流程獨立出來，用一個精簡的範本，甚至獨立子網域，只放進真正必要的第三方元件，藉此限縮攻擊面。
能自己架設的腳本，也比直接從第三方網域載入更容易掌控與稽核。Imperva 的建議清單裡同樣提到，盡可能把程式碼架在自己的伺服器上，而不是仰賴第三方服務，這樣至少能掌握程式碼什麼時候被改動過。
盤點清單是靜態的功課，但光靠清單還不夠，因為前面提過，側錄程式會刻意在管理員面前隱身，巡查這件事本身也要跟著調整做法。
結帳頁的檢查，不能只靠登入中的管理員帳號
既然側錄程式會偵測管理員登入狀態，並在偵測到的當下自動隱身，經營者如果永遠用自己登入的管理員帳號檢查網站，永遠也看不出異常。這一招操作門檻低，不需要額外採購任何工具，卻很容易被忽略。
如果你經營的是網路商店，可以定期用無痕視窗，或是登出管理員帳號、清除瀏覽器快取與 cookie 之後，重新完整走一次「加入購物車、結帳、輸入測試付款資料」的流程，肉眼檢查頁面上有沒有多出可疑的欄位、彈出視窗，或是載入了陌生網域的資源。也可以打開瀏覽器開發者工具的網路分頁，觀察結帳頁實際送出請求的目的地網域，比對是不是都在預期的名單內，像是金流商、CDN、已知的分析工具。
Silent Push 在報告的防禦建議裡明確點出這個做法，網站管理員應該定期用瀏覽器的無痕模式，或是清除快取與瀏覽紀錄之後檢查自己的網站，理由是許多以網頁注入為手法的攻擊，會透過 cookie 辨識出管理員身份，並刻意避開在管理員面前執行惡意程式碼。用沒有管理員身份、也沒有快取資料的視角看網站，才有機會看到那些原本會被隱藏起來的威脅。這個方法之所以有效，正是因為它直接反制了側錄程式偵測到管理員就自我隱藏這個已知的躲避手法。
把卡號欄位交給金流商，用轉導或代管欄位隔開結帳頁
降低被注入的機率之外，還有一種更根本的做法是從架構面下手，如果卡號欄位根本不在自家網域的頁面上，側錄程式就算混進了自家的程式碼，也碰不到卡號。
常見的付款整合方式大致分成兩種。一種是結帳流程整頁導向金流商自己的網域完成付款，網址列會變成金流商的網域，卡號從頭到尾都沒有經過自家網站的程式碼，這種情況下即使自家網站被入侵，Magecart 類攻擊也碰不到卡號。cside 在常見問答裡把這個差異講得很清楚，如果結帳欄位架在自己的網站上，就算用的是 Stripe 或 PayPal 這類金流商，頁面上的第三方腳本仍然可能存取使用者輸入的內容，但如果整頁完全導向金流商自己的網域，Magecart 就沒有機會在那裡側錄卡號。
另一種常見做法是用「代管欄位」技術，把付款欄位用 iframe 嵌回自家結帳頁。畫面上看起來像是自家頁面的一部分，但使用者實際輸入的資料是在 iframe 的範圍裡處理，受瀏覽器的同源政策保護，一定程度上隔開了外層頁面的惡意腳本。basistheory（國際商用支付基礎設施平台）對這種做法的技術說明也提到，這樣的整合方式能協助商家縮小 PCI DSS 的稽核範圍，因為卡號實際上不會經過商家自己的程式碼環境。
但這不代表 iframe 代管欄位就是絕對安全。HUMAN Security（國際資安研究機構）揭露過一種能繞過 iframe 代管欄位保護的側錄手法，證實這不是假設性的風險，而是有具體案例可循。就算後端有做 token 化或加密，也無法完全阻絕風險，cside 的說明點出關鍵，token 化與加密只發生在顧客送出付款之後，而 Magecart 側錄的是使用者打字當下的原始資料，即使整套流程最終都有做 token 化或加密，只要有惡意腳本在頁面上執行，一樣可能在資料被保護之前就先被複製一份。這是串接金流服務當下就該一併考慮的架構選擇，而不是事後才補救的事。
結帳頁程式碼一有變動，就要有告警通知
降低被攻擊的機率是一回事，攻擊萬一還是發生了，多快能知道又是另一回事。
PCI DSS 第 11.6.1 項要求商家針對付款頁面建立變更與竄改偵測機制，能自動偵測頁面內容，或是 HTTP 安全性標頭，包含前面提到的 CSP 標頭本身，有沒有未經授權的變動，並在偵測到偏差時發出告警。這項要求背後的邏輯很直接，CSP 政策一旦被悄悄削弱或改鬆，往往就是後續腳本攻擊得以發生的前提，監控範圍自然要把 CSP 設定本身也納進去。
落地做法是你可以定期，甚至即時比對結帳頁實際載入的腳本清單，跟前面盤點出來的授權清單是否一致，多出來的、來源不明的腳本要立刻列為可疑。檔案異動監控這類機制，原本就用在偵測主機檔案有沒有被竄改，同樣的概念也能延伸監控佈景主題與外掛檔案有沒有被未授權修改，這在 WordPress 與 WooCommerce 環境裡是常見、原理相通的做法，不必依賴單一特定廠商的產品。
定期更新系統本身也是同一條防線的一環。Silent Push 的報告在防禦建議裡特別強調，持續更新 CMS、外掛與修補程式，是減少側錄程式被植入機會的基本功，跟監控告警互為前後手，更新降低被入侵的機率，監控則縮短被入侵之後被發現需要的時間。
電商經營者確認資料外洩後的應變與通報責任
防護做得再周全，也不能排除真的中招的可能，接下來具體要做的事同樣需要先想清楚。
如果你發現網站中招，第一步是移除惡意程式碼本身，並且確認最初的入侵管道已經封住，不是只刪掉看到的那一段程式碼就結束。如果沒有找出攻擊者當初是怎麼進來的，側錄程式很可能會被重新植入，問題只是暫時消失，沒有真正解決。SOCRadar 對應變流程的說明也把這幾個動作講得清楚，回應必須移除惡意程式碼、封鎖最初的存取管道、評估受影響的連線範圍，並且達成金流與外洩通報的相關義務。
接下來要盤點受影響的時間範圍，以及可能被側錄到的訂單與顧客資料範圍，這些資訊會用在後續的通報與鑑識。SOCRadar 也提到商家在應變過程中應該保留的資料類型，包含受影響的檔案、部署歷史紀錄、網站與身份驗證的日誌、標籤管理器的變更紀錄、第三方套件的版本資訊，以及網路流量指標與結帳流程的截圖，這些證據用來判斷攻擊者是怎麼進來的、外洩時間持續了多久，以及哪些交易受到影響。
依合約義務，也要通知配合的金流商與收單機構，這類廠商通常有自己的資安事件通報流程要走。依台灣的個人資料保護法，發現個人資料遭外洩時，負有查明後以適當方式通知當事人的義務，情節重大者還要向主管機關報告，法規細節與罰則不在這裡展開，但這項義務確實存在，不是可以選擇性忽略的環節。
對外溝通也是應變的一部分，清楚說明哪些資料可能外洩、受影響的顧客該怎麼自保，比含糊帶過更能維持顧客的信任，像是提醒對方留意信用卡對帳單的異常扣款，必要時申請換卡。
結帳頁看起來正常，從來不是資料安全的保證，這正是 Magecart 這類攻擊最難纏的地方。它繞過的不是防火牆或加密演算法，而是「看起來一切正常」這個人最容易信任的訊號。CSP、腳本盤點、用訪客視角巡查、把卡號欄位交給金流商網域，還有變更告警，這幾件事沒有哪一件單獨做到就能高枕無憂，但少了任何一件，暴露面都會留下一個缺口。把這些做法排進你的日常維運，而不是等出事才想起來，才是真正能降低風險的做法。