保護付款頁面的 c/side 替代方案（2026 年）
作者 Laís Peixoto
Growth Marketer, Proteside
發佈於
尋找 c/side 替代方案的團隊會找到三個類別：Feroot 及 Jscrambler 等頁面代理程式；Reflectiz 及 SecurityMetrics 等外部監察；以及 Cloudflare Client-Side Security（前稱 Page Shield）等 CDN 或 WAF 模組。Proteside 走第四條路，在腳本之上核實付款本身。選擇由你的結帳接受甚麼開始。
為甚麼團隊會評估其他選項
結帳接受的不只是卡
UPI、PromptPay、PayNow、銀行繳費單及穩定幣沒有可守護的卡表格。這裡的網頁資料竊取是在螢幕上或剪貼簿中調換收款人，這需要把所顯示的資料與所發出的資料比對。
攔截必須自動進行
當調換在單一工作階段內發生，事後審核的警報來得太遲。團隊希望在確認前攔截，而不是等待有人打開控制面板。
保護與證據來自同一工具
中小型營運團隊希望要求 6.4.3 及 11.6.1 的證明由阻止欺詐的同一工具產生，並可直接交給 QSA。
精選名單
| 選項 | 運作方式 | 適合 | 比較 |
|---|---|---|---|
| Proteside | 付款頁面上的一段腳本，把每個 QR 碼、付款識別碼、銀行繳費單條碼、錢包地址及卡欄位與你的伺服器所發出的資料比對，並在確認前攔截調換。 | 透過 UPI、PromptPay、PayNow 或 Pix 等即時支付系統、卡、銀行繳費單或穩定幣收款的商戶，需要以一次安裝同時取得保護及 PCI DSS 證據。 | c/side 與 Proteside |
| Feroot PaymentGuard e DXSecure | 清點付款頁面上的腳本，記錄理由及完整性，並就內容及標頭的變更發出警報；執行期政策強制執行被描述為可選。 | 以卡為中心、需要在網站及流動應用程式之間管理腳本，並為評估員提供報告的營運團隊。 | Feroot 與 Proteside |
| Jscrambler Webpage Integrity | 一個 JavaScript 代理程式，或合成用戶監察，清點腳本、偵測行為偏移，並強制執行攔截及表格保護政策；有一個模組涵蓋要求 6.4.3 及 11.6.1。 | 同時需要保護自家 JavaScript 程式碼（混淆）的公司，以及以 iframe 提供結帳頁面的支付服務供應商。 | Jscrambler 與 Proteside |
| Reflectiz PCI Module | 自動化瀏覽器按時間表從外部訪問付款頁面，網站上沒有程式碼；在介面觸發攔截時，會注入一條排除某個網域的 CSP 政策。 | 無法或不想在頁面放置腳本，並接受偵測後由人手審核的團隊。 | Reflectiz 與 Proteside |
| SecurityMetrics Shopping Cart Monitor | 按間隔從外部掃描付款頁面，模擬結帳，並就新腳本及變更發出警報；該公司自己把產品描述為偵測工具，並表示它不是為預防而建。 | 已經使用 SecurityMetrics PCI 入口網站（問卷、ASV 掃描）並希望在同一處取得要求 6.4.3 及 11.6.1 證據的商戶。 | SecurityMetrics 與 Proteside |
| Cloudflare Client-Side Security (antes Page Shield) | Cloudflare 從代理伺服器向部分頁面抽樣加入僅報告模式的 CSP 標頭，並根據瀏覽器報告建立清單；攔截透過進階層級的允許規則進行。 | 已經在 Cloudflare 後面、希望無需安裝任何東西即可監察腳本的網站。 | Cloudflare Page Shield 與 Proteside |
先選類別，再選供應商
在把一個供應商換成類似的另一個之前，先看類別。c/side、Feroot 及 Jscrambler 等頁面代理程式看到每個真實工作階段並控制運行的內容；Reflectiz 及 SecurityMetrics 等外部監察無需在網站放置程式碼即可提供清單，代價是看不到每一位買家；Cloudflare 等 CDN 或 WAF 模組在邊緣運作，並依賴流量經過該處。這三個類別都源自卡的問題，並以不同方式滿足要求 6.4.3。
就公開文件所描述，它們都不查核螢幕上的 QR 碼、收款人識別碼、繳費單條碼或錢包地址是否商戶所發出的。c/side 在其加密貨幣頁面提到剪貼簿地址被調換，是最接近的，但沒有與所產生資料的比對。這個比對是 Proteside 的類別：它包括腳本清單及 PCI DSS 證據，並加入付款核實。
各選項詳情
Proteside
Proteside 記錄每個付款頁面上甚麼是合法的（每筆收費的資料、表格欄位、已授權的腳本），並在付款人的瀏覽器中持續核實所顯示的內容、所複製的內容以及資料流向。偵測到不符時，它會在付款確認前停止該操作並記錄該次嘗試。
腳本清單與變更歷史構成 PCI DSS 要求 6.4.3 及 11.6.1 的證據。安裝只需在任何電子商務平台加入一行程式碼，或為平台及支付服務供應商進行一次整合，並附有控制面板、API 及警報。
Proteside 是正確選擇的情況: 當你的結帳除卡以外還透過即時支付系統、銀行繳費單或穩定幣收款，當你需要在真實工作階段中攔截收款人調換，或當你想在不更改 CDN 的情況下同時取得保護及 PCI DSS 證據時，選擇 Proteside。
Feroot PaymentGuard e DXSecure
Feroot 的產品以合規為核心：PaymentGuard 以腳本清單、理由、完整性檢查及給 QSA 的證據報告涵蓋要求 6.4.3 及 11.6.1。公開文件提及與警報及營運工具的整合，以及除網站外對 iOS 及 Android 應用程式的覆蓋。
對於卡以外收款的人，要留意的是範圍：公開資料談的是腳本及卡資料，沒有提及 QR 碼、付款識別碼、boleto（巴西銀行繳費單）或加密貨幣錢包。對這些付款方式而言，收款人調換不在該工具所描述的查核範圍內。
Feroot 是正確選擇的情況: 你的首要目標是跨網站及流動應用程式的腳本管理及 PCI DSS 證據，而你的結帳主要以卡收款。
Jscrambler Webpage Integrity
Jscrambler 結合兩個不同的產品：Code Integrity 用於保護及混淆 JavaScript 程式碼，Webpage Integrity 用於清點及控制頁面上的腳本，並附有 PCI DSS 合規模組。公開文件描述了在真實工作階段中攔截的代理程式模式，以及模擬用戶的無代理程式模式。
對於以卡為主要付款方式、希望由同一家公司同時處理程式碼及頁面的團隊，這是成熟的產品。公開資料沒有涉及 Pix、boleto（巴西銀行繳費單）、即時支付 QR 碼或加密貨幣錢包。
Jscrambler 是正確選擇的情況: 你需要保護付款頁面以外的自家 JavaScript 程式碼，或你是以 iframe 提供結帳的服務供應商。
Reflectiz PCI Module
Reflectiz 把自己的方式描述為無代理程式：沙盒瀏覽器模擬用戶旅程，清點腳本（包括 iframe 內的），為要求 11.6.1 監察標頭，並匯出給 QSA 的證據。該平台亦涵蓋私隱及攻擊性測試。
供應商自己的資料解釋，攔截是一段留在頁面上但保持不活躍的腳本，直至在介面中觸發，才開始透過 CSP 排除某個網域。這是一個設計選擇：先偵測，後由人手介入。只向某一位買家出現的詐騙，模擬訪問是觀察不到的。
Reflectiz 是正確選擇的情況: 你的內部政策禁止在付款頁面加入腳本，而你的安全團隊會在採取行動前審核警報。
SecurityMetrics Shopping Cart Monitor
SecurityMetrics 是一家 PCI 評估公司（QSA、ASV），Shopping Cart Monitor 是其入口網站的一部分：附理由的腳本清單、內容及標頭變更偵測、警報以及可匯出給評估員的日誌，網站上無需安裝任何東西。
公開資料對限制很坦率：供應商表示該工具是為偵測而建，並以按間隔拍攝的快照運作。對於需要在顧客仍在頁面上時攔截詐騙的團隊，這種方式可作為真實工作階段攔截的補充。
SecurityMetrics 是正確選擇的情況: 你的 PCI DSS 評估已經透過 SecurityMetrics 進行，而你希望付款頁面證據整合到同一入口網站。
Cloudflare Client-Side Security (antes Page Shield)
該功能在 2026 年 3 月前稱為 Page Shield，現稱 Client-Side Security，適用於透過 Cloudflare 代理的網域。文件描述了腳本、連線及 cookie 的監察、惡意腳本及程式碼變更的偵測，以及可攔截允許名單以外任何內容的內容安全規則。
文件本身解釋了機制：僅報告模式的標頭只在抽樣的回應中發出，因此新腳本可能需要一段時間才會出現。要求 6.4.3 及 11.6.1 在進階層級中涵蓋。Pix、boleto（巴西銀行繳費單）及即時支付系統並未出現在資料中。
Cloudflare Page Shield 是正確選擇的情況: 你的網站已經在 Cloudflare 後面，卡是主要付款方式，而抽樣式腳本監察能滿足你的評估員。
如何評估替代方案
- 1你的頁面顯示哪些付款方式？如果有 UPI、PromptPay、PayNow、銀行繳費單或錢包地址，工具必須把這些資料與你的伺服器所發出的資料比對。
- 2單一被入侵的工作階段內會發生甚麼？在確認前自動攔截，還是發出警報讓人審核？
- 3你可以在付款頁面放置腳本標籤嗎？如果不可以，只有外部監察合適，並附帶它們自己說明的限制。
- 4誰在哪裡接收警報？對小型團隊而言，Slack、Teams、電郵及 webhook 通常足夠；SIEM 饋送對大型營運團隊較重要。
- 5報告是否以可直接交給 QSA 的形式輸出，包含要求 6.4.3 及 11.6.1 的清單、授權及變更歷史？
- 6你的營運是否依賴某個特定 CDN？邊緣模組只適用於已經在該平台上的網站。
常見問題
c/side 最好的替代方案是甚麼？
取決於你的結帳接受甚麼。對於以卡為主的腳本控制，Feroot 及 Jscrambler 涵蓋類似範圍；Reflectiz 及 SecurityMetrics 適合無法在頁面加入程式碼的團隊；Cloudflare Client-Side Security 適合已經在 Cloudflare 後面的網站。對於 UPI、PromptPay、銀行繳費單、穩定幣及其他非卡方式，付款核實只出現在 Proteside 的公開文件中。
c/side 的替代方案需要涵蓋甚麼？
最低限度是觀察真實工作階段、清點及授權腳本、偵測頁面及其標頭的變更，以及為審計員產生報告。如果結帳不止於卡，還要加上所顯示收款人與所發出收款人的比對。
c/side 的競爭對手有哪些？
同屬頁面代理程式類別的有 Feroot、Jscrambler、Source Defense 及 HUMAN Security。外部監察有 Reflectiz 及 SecurityMetrics。CDN 及 WAF 模組有 Cloudflare、Akamai、Imperva 及 F5。Proteside 在這些頁面上與它們全部比較。
Proteside 會取代 c/side 嗎？
取決於你用它做甚麼。在付款頁面上，Proteside 涵蓋清單、腳本攔截及要求 6.4.3 及 11.6.1，並加入付款核實。Fingerprint 的裝置識別及機械人偵測不在 Proteside 的範圍內；在這種情況下，兩個工具並行運作。