2026 独立站 PCI-DSS 自查清单：SAQ A 还是 A-EP 一文搞懂

延伸阅读

更多相关攻略推荐：2026 只选月付 VPS：不锁年付、随时退的试错策略、2026 海外仓/ERP 系统自建部署：独立服务器还是云 VPS？、2026 实测：VPS 上自托管 AI 编程助手——Continue、【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自。

独立站为什么要自己搞懂 PCI-DSS

很多做跨境独立站的朋友，第一次听到 PCI-DSS 都觉得这是大平台才操心的事：我钱都不经手，卡号直接交给 Stripe、PayPal、Adyen 了，关我什么事？这种想法在 2026 年已经相当危险。原因很简单：你的网站虽然不存卡号，但你的结账页上跑着十几个脚本——分析工具、聊天插件、再营销像素、标签管理器——任何一个被污染，卡号就能在用户输入的那一刻被悄悄偷走。这种攻击就叫电子撇油（e-skimming，业内也叫 Magecart）。卡组织、收单银行和支付服务商现在都盯着这块，SAQ 类型填错，不但合规白做，一旦出事还会被追责。

更重要的是，PCI-DSS v4.0.1 已经从 2024 年 12 月 31 日起成为唯一生效的版本，而原先的"最佳实践"要求 6.4.3 和 11.6.1，已经在 2025 年 3 月 31 日转为强制要求。也就是说，今天你再按老黄历做合规，已经不够了。这篇文章就用一份可照着打勾的清单，帮你把"我到底该填 SAQ A 还是 SAQ A-EP"这件事彻底弄明白。

一句话分清 SAQ A 与 SAQ A-EP

判定的核心只有一条，业界常叫"单元素测试（one element test）"：你的结账页里，有没有任何一丁点元素是由你自己的网站生成或投递给浏览器的？

• 如果支付页上所有元素都只、且直接来自一家合规的第三方支付服务商（TPSP），你可以用最简单的 SAQ A，全卷只有约 22 道题目。
• 只要支付页上有任何元素源自你自己的网站（哪怕卡号最后还是直接发给了支付网关），你就落入了 SAQ A-EP，题目数直接飙到约 139–191 道，覆盖漏洞扫描、补丁管理、访问控制、日志审计、渗透测试等一整套技术控制。

这个区别就是"一个字母的差别，可能让你多背 170 条安全要求"。选错了不是多填几张表那么轻松，而是留下真实的安全缺口，出事后收单银行和卡组织照样找你。

三种集成方式各自落在哪一类

把最常见的自建站接法对照一下，范围就一目了然：

• 全重定向（Full Redirect）：用户点"去支付"后，浏览器被带到一个完全由支付商托管的页面（URL 变成 checkout.stripe.com 这种）。你的服务器从不渲染任何卡号输入框。判定：SAQ A。这种最省心，新版的 6.4.3/11.6.1 对你的 SAQ A 评估基本不适用。
• 内嵌 iframe（Embedded Iframe）：结账页上开一个由支付商域名提供的 inline frame，卡号输入框存在于这个 iframe 里、由支付商投递。注意一个关键细节：2025 年 4 月 PCI 安全标委会的澄清指出，嵌入第三方 iframe 可以降低范围，但如果你的父页面能影响支付体验（比如父页上的脚本或 header 改动），父页仍在 PCI-DSS 范围内。也就是说，纯 iframe、且你父页完全不能改它、也不能被脚本污染，才大概率还走 SAQ A；一旦你父页有脚本风险且无法证明隔离，就可能被推到 SAQ A-EP。
• JS SDK / 直接提交（JS SDK / Direct Post）：比如 Stripe Elements、Adyen Components、Checkout.com Frames，由你服务器投递页面、加载支付商的 JS 在浏览器里现场生成卡号输入框；或者你自己的服务器拼出 HTML 表单、action 指向网关。判定：SAQ A-EP，这是最常见的"错填成 SAQ A"的重灾区。

SAQ A 与 SAQ A-EP 的范围差异清单

这里有个容易踩的坑：很多商户以为"用了 iframe 就一定是 SAQ A"。错。如果你的父页面本身是单页应用、结账流程里持续运行着一堆 JS，或者你页面上挂着聊天机器人、标签管理器、再营销像素，你的环境就可能"影响支付安全"，从而进入 A-EP 的更大控制集。PCI 标委会的 FAQ 1588 明确说：SAQ A 商户若用 iframe，必须确认自己的站点不容易受到能影响电商系统的脚本攻击；如果你证明不了，就被推到 SAQ A-EP。

2026 必须落地的两条新规：6.4.3 与 11.6.1

这两条是 v4.0 为对付 Magecart 专门加的，2025 年 3 月 31 日起对所有 SAQ A-EP 和 SAQ D 商户强制生效。即使你下次年审在 deadline 之后，支付商也默认你已具备这些控制；一旦出事，是按这两条标准当场判定的。

• 要求 6.4.3（脚本清单与完整性）：对支付页上加载执行的每一个脚本，都要（1）登记在册并写明业务或技术理由，（2）有办法确认它经过授权，（3）有办法验证其完整性未被篡改。支持手段包括 CSP、SRI、哈希校验、代理校验等。
• 要求 11.6.1（篡改检测）：部署一套变更与篡改检测机制，在消费者浏览器实际收到的支付页内容和具有安全影响的 HTTP 头被未授权修改时告警。检测至少每周一次，或按你自己的定向风险分析（TRA）定义频率。网页监控和基于代理的方案都被 PCI 标委会点名为有效方法。

一个常被引用的数据是：2024 年 Verizon 支付安全报告显示，约 40% 的支付页脚本能接触到 PII 或持卡人数据，每个结账页平均加载约 18 个脚本。每一个都是潜在后门。

支付页脚本管理落地：脚本清单 + 完整性校验

照着 6.4.3 做，先把下面这张清单跑一遍：

• 为每一个支付页建立脚本清单，外部脚本和页面内联脚本都要登记。
• 为每个脚本写明"为什么必须有它"——"一直都有"不算理由，必须是业务或技术必要性。
• 指定一个有权限的人审批每个脚本的上线或变更，形成授权白名单。
• 建立完整性校验机制，通常用 SHA-256 等哈希，检测脚本内容是否被改动。
• 结账流跨多个 URL（购物车、配送、支付、确认）时，每个涉及持卡人数据的页面都要单独建清单。

注意一个反直觉的点：CSP 和 SRI 很有用，但它们不等于真正的防护。CSP 只能限制脚本从哪加载，看不到脚本运行后到底干了什么；SRI 对静态哈希有效，但现代结账页通过标签管理器、个性化脚本频繁变动，静态哈希会失效。所以 PCI 标委会的电商工作组提醒：单靠 CSP 无法满足 6.4.3 和 11.6.1 的全部要素，它缺少对运行时篡改行为的告警能力。真正的稳妥做法是行为级监控（对脚本行为做实时沙箱与管控），至少也要有能覆盖整条支付链路的检测。

用 CSP 与 SRI 守住支付页

尽管有局限，CSP 和 SRI 仍是落地时最常用、最该先做的基线控制。一个推荐的部署节奏是：先在 Report-Only 模式下跑，收集违规而不阻断页面，等报告干净了再切到强制模式。

# 第一步：仅报告，不阻断（先收集违规）
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; frame-src https://checkout.your-psp.com; style-src 'self'

# 第二步：确认无误后切强制模式，用白名单锁死脚本来源
Content-Security-Policy: default-src 'self'; script-src 'self' https://checkout.your-psp.com https://js.adyen.com; frame-src https://checkout.your-psp.com; connect-src 'self' https://api.yoursite.com

# 第三步：加 report-uri 收告警（被篡改或外联会触发浏览器上报）
Content-Security-Policy: default-src 'self'; script-src 'self'; report-uri https://your-report-endpoint.example.com/csp

几个实操要点：

• pin 死版本号：第三方脚本永远引用具体版本（如 moment/2.30.1），不要用 latest，避免上游静默更新改变你的支付页行为。
• SRI 完整性属性：对外链脚本加 integrity 哈希和 crossorigin="anonymous"，文件一旦被改哈希不匹配，浏览器直接拒绝执行。
• 内联脚本用 nonce：CSP 默认禁内联 JS，给内联脚本配一次性 nonce 值放行，而不是开 unsafe-inline。
• connect-src 阻断外泄：即使 skimmer 跑了，浏览器也会拦住它向未知域名发数据，偷不走。

<!-- SRI 示例：卡号页外链脚本加哈希 -->
<script src="https://cdn.example.org/libs/moment/2.30.1/moment.min.js"
        integrity="sha512-ZXhhbXBsZV9pbnRlZ3JpdHlfaGFzaF9fZG9fbm9fY29weV9fZ2VuZXJhdGVfcmVhbF9zcmlfaGFzaF9fX19fCg=="
        crossorigin="anonymous"></script>

<!-- 内联脚本用 nonce 放行，不要用 unsafe-inline -->
<script type="text/javascript" nonce="REPLACE_WITH_ONE_TIME_NONCE">
  // 你的内联逻辑
</script>

11.6.1 篡改检测怎么做

11.6.1 看的是"浏览器实际收到的页面"，而不是你服务器上存的那份——因为 e-skimming 常在传输途中或依赖链里动手脚，恶意改动只出现在渲染后的页面。落地要点：

• 部署自动化变更检测，把当前脚本和 header 跟授权基线定期比对。人工抽查不算数。
• 除了脚本，还要监控有安全影响的 HTTP 头（Content-Security-Policy、X-Frame-Options、Strict-Transport-Security 等）。
• 检测到未授权变更时，及时告警到负责支付页安全的人员，并标明"改了什么、何时、哪个页面"。
• 扫描频率至少每周一次，最佳实践是每天或更频繁，并把频率写进文档持续执行。
• 所有扫描结果、变更、告警都要留日志备查，形成连续时间线。发现异常要有"调查—判断—更新基线或处置—记录"的书面流程。

SAQ 类型错配的踩雷清单

• 用着 JS SDK 却填 SAQ A：Stripe Elements、Adyen Components 这类在页面现场生成卡号框的，几乎都该是 A-EP，错填等于提交了不准确的合规声明。
• iframe 父页有脚本风险却不证明隔离：以为嵌了 iframe 就万事大吉，结果父页挂满第三方脚本又证明不了安全，被推到 A-EP 还缺控制。
• 以为"不存卡号就永不入 A-EP"：错。只要支付页任何元素源自你网站，范围就进来了，服务器碰不碰卡号不是唯一判据。
• 收单银行拒收或事后追责：填错 SAQ 是常见也最严重的合规错误，银行可能直接拒，或收了但出事后发现你其实不合规、暴露无遗。
• 等新版本 deadline 才动手：6.4.3/11.6.1 已过强制日，等下次年审不豁免，出了事按现行标准当场判。

给独立站的落地自检清单

• 画出你的支付架构图，标出每个支付页元素由谁控制（你 or 支付商）。
• 按"单元素测试"判定 SAQ A 还是 A-EP，别凭感觉。
• 若走 A-EP：建脚本清单、授权流程、完整性校验（6.4.3）。
• 若走 A-EP：上篡改检测机制，至少每周跑，并用 CSP report-uri 收告警（11.6.1）。
• 先 Report-Only 再强制，pin 版本、加 SRI、内联用 nonce。
• 定期（季度）复核第三方脚本清单，管理好 CMS/后台账号的多因素认证，防止直接被攻破。

延伸阅读：想为独立站挑一台合适的机器，可看 2026 跨境电商 VPS 指南、电商 VPS 选型、VPS 安全基础 与 什么是 CN2 GIA。