考虑到 TLS 具有可靠的配置（即证书固定），我没有理由不这样做，您需要通过加密此信息来计算您试图减轻的业务风险。

问问自己，这样做你会得到什么？您正在缓解哪种类型的攻击媒介？

您将如何生成、分发和管理密钥，加密/解密数据的代码和密钥在哪里？当（不是如果）密钥被提取时会发生什么[即你会为所有事情使用相同的密钥吗？]？

TLS 的一个重点是解决这个问题 - 一种跨不受信任的网络传输数据的安全方式，最好使用临时密钥作为实际加密部分。自己这样做是可能的，但危险地接近“自己动手”，因为您将不得不解决诸如密钥存储等问题。

根据您的后端网络的设置方式，您可能需要查看您是在执行完全端到端加密，还是您的 TLS 终止于负载均衡器或路由器。然而，这是一个单独的话题。

标准做法是使用 https 作为 REST API 调用的基线保护。

此外（超出标准做法，但某些人更喜欢），发送到服务器或从服务器接收的选定信息可能会使用 AES 等进一步加密。例如，如果有敏感内容，您可以选择选择那些要加密的东西，这样即使 https 以某种方式被破坏或配置错误，你也可以从加密中获得另一层保护。很容易认为，理论上，TLS 是那么坚如磐石，但是这些年来暴露出各种严重的漏洞，例如 beast、poodle、sweet32。这些可能只影响某些密码套件，但如果您对允许的 TLS 密码套件的配置不小心，您可能容易受到其中一个或多个的攻击。并非所有服务器-客户端对都支持 TLS 1.3；有时会说 TLS 1.3“

在之前的项目中，一位渗透测试人员要求对此类敏感内容进行加密，尽管我们已经在使用 https。

其他人已经提出了密钥管理的问题。如果您要这样做，您肯定不会为每个手机使用一个密钥来共享。相反，每个移动设备和服务器都应该使用唯一的密钥。一种方便的方法是至少部分从推送通知令牌中获取共享秘密，这些令牌对于每个移动设备都是唯一的，并且移动设备和服务器都知道（假设推送通知更早发送到服务器，例如，仅通过 TLS 和未加密）。

该站点上还有其他问题似乎正在解决相同的问题，但不完全是，经过仔细检查。

1) 对于这个问题，尽管它也使用 https 和 REST API，但它适用于 Web 应用程序，而不是移动应用程序。因此，接受的答案可以正确地说：

对于一个设计在浏览器中运行的网络应用来说，应用层加密的安全价值基本为零。为什么？因为执行应用层加密的代码必须首先传输到客户端。如果传输层加密被破坏，则该代码可能会被篡改，从而使攻击者受益。

与移动应用程序的一个重要区别是应用程序层加密代码不必首先传输到客户端。它驻留在移动应用程序中。

2）对于这个问题，没有理由断言仅 SSL 就足够了。

3)这个问题是关于在越狱或有根手机的情况下保护通过 TLS 发送的数据。我同意在这种情况下，您应该专注于手机上的防篡改机制，以防止使用像 Frida 这样的工具来挂钩您的功能。

4）这个问题也解决了一个不同的问题。