按PayPal推荐方式集成Express Checkout是否安全？

你的担忧非常合理——全局变量确实存在被篡改的风险，尤其是当页面存在未被过滤的用户输入（可能导致XSS）或者外部脚本加载顺序失控时。下面针对你的两个问题逐一分析：

1. 是否应该通过应用内HTTP请求获取资源并赋值给全局const？ #

首先，不推荐自行通过HTTP请求获取PayPal脚本再手动执行，原因有几点：

• 跨域与合规问题：PayPal的脚本托管在其官方域名下，虽然可能允许跨域请求，但自行请求后执行（比如用eval或动态创建script标签）可能破坏PayPal的预期加载流程，甚至触发浏览器的安全限制。
• 完整性验证缺失：直接引入官方脚本时，你可以利用Subresource Integrity (SRI) 来确保脚本未被篡改。比如给script标签加上integrity和crossorigin属性：

  <script 
    id="paypal-checkout-script"
    src="https://www.paypalobjects.com/api/checkout.js"
    integrity="sha256-xxx..."
    crossorigin="anonymous"
  ></script>
  

  这个哈希值可以从PayPal官方文档获取，浏览器会验证脚本内容与哈希匹配，不匹配则不会执行，从根源上防止篡改。
• 全局const的局限性：即使你声明const paypal，如果恶意脚本在PayPal脚本加载前执行，它可以先覆盖全局的paypal变量（因为const是块级作用域，全局的var/let可以被重新赋值，除非你在全局作用域提前声明const，但这样PayPal脚本加载时可能会报错，因为它要给全局paypal赋值）。反而不如用SRI确保脚本本身的完整性更可靠。

如果想进一步隔离全局变量，可以考虑将PayPal按钮放在一个独立的iframe中，iframe只加载PayPal的必要脚本和按钮逻辑，这样主页面的全局变量不会影响到iframe，反之亦然。不过这会增加组件的复杂度，需要根据你的应用场景权衡。

2. 若继续此方式，我是否需承担责任？何时风险不再属于应用责任？ #

责任边界主要取决于风险的来源：

• 你需要承担责任的情况：如果你的Angular应用存在XSS漏洞（比如未对用户输入进行正确过滤，导致恶意脚本被注入到页面中），进而篡改了paypal变量，那么这个风险属于应用的安全问题，你需要负责修复XSS漏洞。
• 风险不属于应用责任的情况：如果恶意脚本来自用户设备本身（比如用户安装了恶意浏览器扩展、设备被病毒劫持，或者网络中间人的篡改但你已经启用了HTTPS和SRI），这种情况下你无法控制用户端的环境，风险就不再属于应用的责任。

总结一下，最稳妥的做法是：

• 启用HTTPS确保传输过程中脚本不被篡改；
• 给PayPal的script标签添加SRI属性，验证脚本完整性；
• 确保你的应用没有XSS漏洞，对所有用户输入进行严格的过滤和转义。

内容的提问来源于stack exchange，提问作者Jonathan002