X-Requested-With标头的含义是什么？

jQuery和其他框架添加以下标头：

X-Requested-With：XMLHttpRequest

为什么需要这个？为什么服务器要对AJAX请求与常规请求进行不同的处理？

更新：我刚刚找到了一个使用此标头的真实示例：https : //core.spreedly.com/manual/payment-methods/adding-with-js。如果要求付款处理器不使用AJAX，则完成后会重定向回原始网站。如果使用AJAX请求，则不会进行重定向。

出于安全性的考虑，有一个很好的理由-这可以防止CSRF攻击，因为未经服务器通过CORS的同意，无法将此标头添加到AJAX请求跨域中。

跨域仅允许以下标头：

• 接受
• 接受语言
• 内容语言
• 最后事件ID
• 内容类型

任何其他原因都会导致在CORS支持的浏览器中发出“飞行前”请求。

没有CORS，就不可能添加X-Requested-With到跨域XHR请求。

如果服务器正在检查是否存在此标头，则它知道该请求不是从攻击者的域发起的，该攻击者试图使用JavaScript代表用户提出请求。这还会检查请求是否不是从常规HTML表单发布的，如果不使用令牌，则很难确定该请求不是跨域的。（但是，尽管您将使旧的浏览器容易受到攻击，但是在支持的浏览器中可以选择检查Origin标头）。

发现新的Flash旁路

您可能希望将其与令牌结合使用，因为如果有重定向步骤，则 OSX上Safari上运行的Flash 可以设置此标头。看来它也可以在Chrome上使用，但现已修复。这里有更多详细信息，包括受影响的不同版本。

OWASP建议将其与原始和引荐检查结合使用：

此防御技术在“跨站点请求伪造的鲁棒防御”的第4.3节中专门讨论。但是，Mathias Karlsson早在2008年和2015年就记录了使用Flash绕过这种防御的漏洞，以利用Vimeo中的CSRF漏洞。但是，我们认为Flash攻击无法欺骗Origin或Referer标头，因此通过同时检查这两个标头，我们认为这种检查组合应可防止Flash绕过CSRF攻击。（注意：如果有人可以确认或反驳这种信念，请告诉我们，以便我们更新本文）

但是，由于已经讨论的原因，检查Origin可能很棘手。

更新资料

在此处撰写有关CORS，CSRF和X-Requested-With的更深入的博客文章。

确保您阅读了SilverlightFox的答案。它突出了一个更重要的原因。

原因主要是，如果您知道请求的来源，则可能需要对其进行一些自定义。

例如，假设您有一个包含许多食谱的网站。然后，您可以使用自定义jQuery框架根据配方单击的配方将配方滑入容器。链接可能是www.example.com/recipe/apple_pie

现在通常返回整页，页眉，页脚，配方内容和广告。但是，如果有人正在浏览您的网站，则其中的某些部分已经加载。因此，您可以使用AJAX获取用户选择的配方，但是为了节省时间和带宽，请不要加载页眉/页脚/广告。

现在，您可以像这样为数据编写辅助端点，www.example.com/recipe_only/apple_pie但这很难维护并与他人共享。

但是，仅检测到它是一个发出请求的ajax请求，然后仅返回部分数据会更容易。这样，用户浪费更少的带宽，站点显得响应更快。

框架仅添加标头，因为某些框架可能会发现跟踪哪些请求是ajax以及哪些不是ajax很有用。但是使用这种技术完全取决于开发人员。

实际上有点类似于Accept-Language标题。浏览器可以请求网站，请向我显示该网站的俄语版本，而无需在URL中插入/ ru /或类似内容。

一些框架使用此标头检测xhr请求，例如grails spring security使用此标头标识xhr请求并给出json响应或html响应作为响应。

大多数Ajax库（从v2.1开始的Prototype，JQuery和Dojo）都包含一个X-Requested-With标头，该标头指示该请求是由XMLHttpRequest发出的，而不是通过单击常规超链接或表单提交按钮触发的。

来源：http : //grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html