我们正在将我们的Web应用程序架构转变为基于微服务的架构。关于提供内容的REST API（简称JSON）是否应该考虑对内容进行编码以确保其安全，或者是否采用该内容并显示内容的消费者（例如，以HTML格式提供），我们就此进行了内部辩论。或以其他方式使用它）应负责该编码。用例是为了防止XSS攻击等。
提供商的立场是“好吧，我们不知道如何为每个人编码，或者你将如何使用内容，所以消费者当然应该对内容进行编码。”
消费者的立场是“有一个提供商和多个消费者，所以在提供API中做一次比在每个消费者都这样做更安全。”
对此有什么普遍接受的最佳做法以及为什么？
答案 0 :(得分：4)
通常，当通过“内部”进程（无论可能意味着什么）时，数据应以任何“内部”格式存储或编码。所选格式通常用于最小化编码/解码步骤并防止数据丢失。
然后，在输出时，使用任何输出格式对数据进行编码。防止数据丢失很重要，但正确的转义和格式化也是关键。
因此，例如，对于内部API，二进制格式的数据可能就足够了。但是当您输出JSON或HTML或XML或PDF时，您必须适当地编码和转义数据以适合输出格式。
这里重要的一点是，不同的输出格式具有不同的“安全”概念。对于JSON来说，什么是“安全”的HTML可能不安全，对JSON来说安全的可能对SQL不安全。数据在输出时进行专门编码，以便您可以对任务使用正确的编码。您不能假设此步骤是提前完成的，也不应该将输出函数放在能够确定是否必须进行编码的位置。如果您遵守规则：“输出功能始终为安全编码”，那么您将永远不必担心数据注入攻击。
答案 1 :(得分：3)
我想说的两个要点如下：
如果您遵循这两条规则，那么您将完成95％的可靠性和安全性工作。
至于你的具体问题，一个好的做法是中间立场：提供商默认 一个“通用”编码，但消费者可以（可选）询问提供商的特定编码然后可以应用 - 这允许提供者支持许多可能不同类型的愚蠢，轻量级客户端，并且可以在以后使用额外编码进行扩展而不会破坏API。
答案 2 :(得分：3)
我坚信，在安全领域成为优秀公民需要做出贡献的是消费者和提供者。
作为提供商，我想确保提供安全的产品。我不需要知道我的客户将使用我的产品的上下文，我需要知道的是我将如何交付它。如果我的传递是JSON，那么我可以使用该上下文在发送之前转义我的数据，类似于XML，纯文本等。此外，还有一些传输方法已经有助于安全性。 JSONP就是这样一种交付方式。这可确保有效消耗有效负载。
作为消费者，在我们的环境中没有人是最终消费者，我们都是最终终端客户的提供者（最终用户通过网络浏览器。）。因此，我们还必须在此端保护数据。我永远不会相信黑盒子API为我做这项工作，我总是要确保有效的有效载荷。有许多工具，OWASP的ESAPI项目浮现在脑海中，这将有助于通过数据上下文进行清理。请记住，您最终会将此数据发送给最终用户（浏览器），如果出现问题，您将无法推卸责任。无论漏洞在哪里，您的服务都将被视为易受攻击的服务。此外，作为消费者，您可能无法始终依靠黑匣子提供商及时修复其缺陷。如果他们的支持缺乏或者他们有更高的优先级怎么办？这是否意味着您继续为最终用户提供已知缺陷？
安全性与层次有关，在源点和端点都有安全保障。