不幸的是，除非您嗅探和检查自己的流量，否则您无法...我的建议是不要使用未指示用于处理敏感信息的协议的内置浏览器

正如@StefHeylen 所说，一般来说你不能。正如@d1str0 所说，Burp 是一种查看流量是否加密的方法，如果您可以通过它代理应用程序。

但实际上比这更糟糕 - 移动应用程序并不总是只与服务器建立单一连接。他们在某些部分使用 HTTP 并在其他部分使用 HTTPS 并不少见。他们还可以做一些普通浏览器通常不会触及的其他技巧。例如，如果他们无法与特定服务器建立安全连接，他们可以证书 pin 并拒绝运行。

因此，完全有可能让移动应用程序在代理时拒绝运行（因为它们连接到具有特定证书的特定 HTTPS 服务器，这意味着 Burp 失败），但随后通过未加密的方式将支付数据发送到不同的服务器。观察这一点的唯一方法是通过使用 Wireshark 之类的数据包检查 - 你会看到一堆加密数据，然后一些未加密的数据（通常是 JSON 或 XML）被发送到不同的服务器。

支付数据也可以正确发送，然后用于统计监控的第三方脚本（例如，查看用户通过应用程序中的表单有多远）通过未加密的渠道发送相同的详细信息，因为应用程序开发人员没有排除支付领域。

整个移动应用程序系统一团糟——我赞同 Stef 的建议，尽可能避免使用应用程序付款。如果不能，请考虑为这些付款使用特定的卡，您会定期监控这些卡是否存在异常交易。

使用 BurpSuite 之类的代理工具将允许您测试该特定应用程序是否允许或禁止错误的 HTTPS 连接。

在 iOS 9 中，应用程序中的 HTTPS 已为任何网络调用启用。您可以暂时绕过它，但它很快就会始终只适用于所有网络调用的 HTTPS。

从 iOS 9.0 和 OS X v10.11 开始，应用程序可以使用名为 App Transport Security (ATS) 的新安全功能，并且默认启用。它通过对基于 HTTP 的网络请求实施额外的安全要求，提高了应用程序和 Web 服务之间连接的隐私和数据完整性。具体来说，启用 ATS 后，HTTP 连接必须使用 HTTPS (RFC 2818)。尝试使用不安全的 HTTP 连接失败。此外，HTTPS 请求必须使用安全通信的最佳实践。

NSAppTransportSecurity