无论如何，我都不是安全专家，但我喜欢创建 REST 样式的 Web 服务。
在创建需要确保其传输的数据安全的新服务时。我们已经就哪种方法更安全进行了辩论 - REST 与 HTTPS 或 SOAP WS 与 WS-Security。
我的印象是我们可以对所有 Web 服务调用使用 HTTPS，而且这种方法是安全的。我的看法是，“如果 HTTPS 对银行和金融网站来说足够好，那对我来说就足够好了”。再说一次，我不是这个领域的专家，但我认为这些人已经对这个问题进行了相当深入的思考，并且对 HTTPS 很满意。
一位同事不同意，并说 SOAP 和 WS-Security 是唯一的出路。
网络似乎在这方面无处不在。
也许这里的社区可以权衡每个人的利弊？谢谢！
【问题讨论】：
标签： web-services security rest soap
HTTPS 保护了通过网络传输消息的安全，并为客户端提供了有关服务器身份的一些保证。这对您的银行或在线股票经纪人来说很重要。他们对验证客户端的兴趣不在于计算机的身份，而在于您的身份。因此，卡号、用户名、密码等用于对您进行身份验证。然后通常会采取一些预防措施来确保提交的内容没有被篡改，但总的来说，会话中发生的任何事情都被视为由您发起。
WS-Security 提供从消息创建到消息使用的机密性和完整性保护。因此，不是确保通信内容只能由正确的服务器读取，而是确保它只能由服务器上的正确进程读取。而不是假设安全启动会话中的所有通信都来自经过身份验证的用户，每个通信都必须签名。
这里有一个涉及裸体摩托车手的有趣解释：
因此，WS-Security 提供了比 HTTPS 更多的保护，而 SOAP 提供了比 REST 更丰富的 API。我的观点是，除非您真的需要额外的功能或保护，否则您应该跳过 SOAP 和 WS-Security 的开销。我知道这有点逃避，但是关于多少保护实际上是合理的（不仅仅是建造什么很酷）需要由那些熟悉问题的人来决定。
【讨论】：
参见wiki 文章：
在点对点情况下，机密性和数据完整性也可以通过使用传输层安全性 (TLS) 来强制 Web 服务，例如通过 https 发送消息。
然而，WS-Security 解决了维护消息完整性和机密性的更广泛问题，直到消息从始发节点发送后，提供所谓的端到端安全性。
即：
【讨论】：
REST 安全性依赖于传输，而 SOAP 安全性则不。
REST 从底层传输继承安全措施，而 SOAP 通过 WS-Security 定义自己的安全措施。
当我们谈论 REST 时，通过 HTTP - 应用 HTTP 的所有安全措施都被继承，这被称为传输级安全性。
传输级别的安全性，仅在您的信息在线时保护您的信息 - 一旦它离开线路，信息就不再受到保护。
但是，对于 WS-Security，它的消息级安全性 - 即使消息离开传输通道，它仍然会受到保护。此外 - 使用消息级别的安全性，您可以部分加密消息 [不是整个消息，而只是您想要的部分] - 但使用传输级别的安全性，您不能这样做。
WS-Security 具有身份验证、完整性、机密性和不可否认性措施，而 SSL 不支持不可否认性 [它支持 2-legged OAuth]。
在性能方面，SSL 比 WS-Security 快得多。
谢谢...
【讨论】：
从技术上讲，您的措辞方式都不正确，因为 SOAP 方法的通信不安全，并且 REST 方法没有说明任何关于验证合法用户的内容。
HTTPS 防止攻击者从eavesdropping 进行两个系统之间的通信。它还验证主机系统（服务器）实际上是用户打算访问的主机系统。
WS-Security 防止未经授权的应用程序（用户）访问系统。
如果 RESTful 系统具有验证用户身份的方法，并且具有 WS-Security 的 SOAP 应用程序使用 HTTPS，那么两者实际上都是安全的。这只是呈现和访问数据的一种不同方式。
【讨论】：
我每天都在这个领域工作，所以我想总结一下这方面的优秀 cmets，以结束这个问题：
SSL (HTTP/s) 只是一层确保：
WS-Security 和相关标准/实现使用 PKI：
最后一点对于服务请求很重要，因为客户端（调用者）的身份对于了解他们是否应该被授权从服务接收此类数据至关重要。 标准 SSL 是单向（服务器）身份验证，不会识别客户端。
【讨论】：
Brace yourself, here there's another coming :-)
今天我必须向我的女朋友解释 WS-Security 与 HTTPS 的表达能力之间的区别。她是一名计算机科学家，因此即使她不了解所有的 XML 庞然大物，她也能理解（可能比我更好）加密或签名的含义。但是我想要一个强烈的形象，这可以让她真正了解事物的用途，而不是它们是如何实现的（稍后出现，她没有逃避它:-)）。
所以事情是这样的。假设您赤身裸体，您必须将摩托车开到某个目的地。 在 (A) 的情况下，你穿过一条透明的隧道：你唯一不会因猥亵行为而被捕的希望是没有人在看。这并不是你能想出的最安全的策略……（注意那家伙额头上的汗水:-)）。这等同于明确的 POST，当我说“等效”时，我的意思是。 在 (B) 的情况下，你的情况更好。隧道是不透明的，所以只要您进入其中，您的公共记录就是安全的。然而，这仍然不是最好的情况。您仍然必须离开家并到达隧道入口，一旦走出隧道，您可能必须下车并走到某个地方......这适用于HTTPS。诚然，您的消息在跨越最大的鸿沟时是安全的：但是一旦您在另一边传递了它，您真的不知道它必须经过多少阶段才能到达处理数据的真正点。当然，所有这些阶段都可以使用不同于 HTTP 的东西：例如，一个经典的 MSMQ 缓冲无法立即提供服务的请求。如果有人在预处理过程中潜伏您的数据，会发生什么？嗯。 （把这个“嗯”读成墨菲斯在句子“你认为你呼吸的是空气吗？”结尾处所说的那个）。 这个比喻中的完整解决方案 (c) 非常简单：给自己穿一些该死的衣服，尤其是骑摩托车时戴上头盔！！！因此，您可以安全地四处走动，而不必依赖环境的不透明性。希望这个比喻很清楚：衣服随你而去，不管是什么意思或周围的基础设施，就像消息级别的安全一样。此外，您可以决定遮盖一部分但透露另一部分（您可以根据个人情况这样做：机场安检可以脱掉您的夹克和鞋子，而您的医生可能有更高的访问权限），但请记住，短袖衬衫是即使你为自己的二头肌感到骄傲也是不好的做法 :-)（最好是马球或 T 恤）。
我很高兴地说她明白了！不得不说，衣服的比喻很厉害：我很想用它来介绍政策的概念（迪斯科俱乐部不让你穿运动鞋；你不能穿着内衣去银行取钱，虽然在冲浪时保持平衡是完全可以接受的外观；等等）但我认为一个下午就足够了 ;-)
架构 - WS, Wild Ideas
【讨论】：
REST Over HTTPS 应该是一种安全的方法，只要 API 提供者实现对服务器端的授权。在 Web 应用程序的情况下，我们所做的是通过 HTTPS 和一些身份验证/授权访问 Web 应用程序，传统上 Web 应用程序没有安全问题，那么 Restful API 也可以毫无问题地应对安全问题！
【讨论】：
如果您的 RESTFul 调用来回发送嵌入在 HTTP 请求的 Html 正文中的 XML 消息，您应该能够在使用 XML 消息时获得 WS-Security 的所有好处，例如 XML 加密、证书等http 提供的任何安全功能，例如 SSL/TLS 加密。
【讨论】：
正如你所说，REST 对银行来说已经足够好了，所以对你来说应该也足够好了。
安全性有两个主要方面：1）加密和 2）身份。
以 SSL/HTTPS 传输可通过网络提供加密。但是您还需要确保两台服务器都可以确认他们知道他们在与谁交谈。这可以通过 SSL 客户端证书、共享机密等。
我确信有人可以证明 SOAP “更安全”，但可能没有任何重要意义。裸体摩托车手的比喻很可爱，但如果准确则意味着整个互联网都是不安全的。
【讨论】：
答案实际上取决于您的具体要求。
例如，您是否需要保护您的网络消息或不需要机密性，而您只需要对终端方进行身份验证并确保消息完整性？如果是这种情况——而且通常是使用 Web 服务——HTTPS 可能是错误的锤子。
但是 - 根据我的经验 - 不要忽视您正在构建的系统的复杂性。不仅 HTTPS 更易于正确部署，而且依赖于传输层安全性的应用程序更易于调试（通过普通 HTTP）。
祝你好运。
【讨论】：
我还没有添加评论所需的代表，否则我只会将此添加到贝尔的回答中。我认为贝尔在总结这两种方法的顶级优缺点方面做得非常好。您可能需要考虑的其他几个因素：
1) 您的客户端和您的服务之间的请求是否需要通过需要访问有效负载的中介？如果是这样，那么 WS-Security 可能更合适。
2) 实际上，可以使用 SSL 向服务器提供有关客户端身份的保证，该功能使用称为相互身份验证的功能。但是，由于配置的复杂性，这在一些非常专业的场景之外并没有太多用处。所以贝尔说得对，WS-Sec 更适合这里。
3) 通常，由于证书管理问题，SSL 的设置和维护（即使在更简单的配置中）有点困难。有人知道如何为您的平台执行此操作将是一大优势。
4) 如果您可能需要进行某种形式的凭证映射或身份联合，那么 WS-Sec 可能值得付出这些开销。并不是说你不能用 REST 做到这一点，你只是有更少的结构来帮助你。
5) 将所有 WS-Security goop 放到客户端的正确位置可能比您想象的要痛苦。
最终，尽管它确实取决于很多我们不太可能知道的事情。对于大多数情况，我会说这两种方法都“足够安全”，因此这不应该是主要的决定因素。
【讨论】：