从客户端的角度来看，这些头文件在哪里实现并不重要；只是它们是否被实施。

但是，从部署的角度来看，WAF应该只被视为一道额外的防线，而不是单一的防线。这意味着应该在 Web 应用程序本身中进行正确的输入检查并正确设置安全标头，至少对于大多数标头而言：HPKP 当然只能在拥有可能是 WAF 的证书的 TLS 端点上设置（如果它应该被设置，因为它已被弃用）。

从开发的角度来看，在 Web 应用程序本身中设置安全标头也更好。开发人员应该知道特定输入的预期类型是什么以及应该如何检查它们，开发人员还知道应用程序是如何工作的，例如最严格的 Content-Security-Policy 可以是什么。相反，WAF 通常由对应用程序没有深入了解的不同团队部署，因此无法轻松地将安全标头设置为应用程序可接受的最严格值。

因此，只有在应用程序本身无法设置时才应在WAF中设置，第三方应用程序可能会出现这种情况。但是，作为额外的防线，WAF 仍可用于确保标头存在且足够严格，因为开发人员可能忘记设置它们。

只是出于一些想法，不用说这是一个正确的建议：

• 检查您需要哪些级别的灵活性 - 如果需要在特殊情况下设置其中一些标头（例如，取决于您的应用程序的状态），您可能没有机会只能将它们保留在应用程序中。
• 如果 WAF 背后有多个应用程序，你能确定它们都需要相同的规则集吗？条件规则可能比一般规则更难实施
• 您是否希望将您的规则置于源代码控制之下（这可以记录谁在何时实施了哪些规则）？那么它们应该是您的应用程序的一部分，而不是附加层

如果您不想混合配置（如：在此处设置一些标头，在此处设置一些标头），请将它们保留在您的应用程序中