为了防止CSRF的***，我们建议修改浏览器在发送POST请求的时候加上一个Origin字段，这个Origin字段主要是用来标识出最初请求是从哪里发起的。如果浏览器不能确定源在哪里，那么在发送的请求里面Origin字段的值就为空。

隐私方面：这种Origin字段的方式比Referer更人性化，因为它尊重了用户的隐私

1、Origin字段里只包含是谁发起的请求，并没有其他信息 (通常情况下是方案，主机和活动文档URL的端口)。跟Referer不一样的是，Origin字段并没有包含涉及到用户隐私的URL路径和请求内容，这个尤其重要。

2、Origin字段只存在于POST请求，而Referer则存在于所有类型的请求。

随便点击一个超链接（比如从搜索列表里或者企业intranet），并不会发送Origin字段，这样可以防止敏感信息的以外泄露。
在应对隐私问题方面，Origin字段的方法可能更能迎合用户的口味。
服务端要做的：用Origin字段的方法来防御CSRF***的时候，网站需要做到以下几点：
1、在所有能改变状态的请求里，包括登陆请求，都必须使用POST方法。对于一些特定的能改变状态的GET请求必须要拒绝，这是为了对抗上文中提到过的论坛张贴的那种危害类型。
2、对于那些有Origin字段但是值并不是我们希望的（包括值为空）请求，服务器要一律拒绝。比如，服务器可以拒绝一切Origin字段为外站的请求。
安全性分析：虽然Origin字段的设计非常简单，但是用它来防御CSRF***可以起到很好的作用。

1、去掉Origin字段。由于支持这种方法的浏览器在每次POST请求的时候都会带上源header，那么网站就可以通过查看是否存在这种Origin字段来确定请求是否是由支持这种方法的浏览器发起的。这种设计能有效防止***者将一个支持这种方法的浏览器改变成不支持这种方法的浏览器，因为即使你改变浏览器去掉了Origin字段，Origin字段还是存在，只不过值变为空了。这跟Referer很不一样，因为Referer 只要是在请求里去掉了，那服务器就探测不到了。
2、DNS重新绑定。在现有的浏览器里面，对于同站的XMLHttpRequests，Origin字段可以被伪造。只依赖网络连接进行身份验证的网站应当使用在第2章里提到的DNS重新绑定的方法，比如验证header里的Host字段。在使用Origin字段来防御CSRF***的时候，也需要用到DNS重新绑定的方法，他们是相辅相成的。当然对于在第四章里提到的CSRF防御方法，也需要用到DNS重新绑定的方法。
3、插件。如果网站根据crossdomain.xml准备接受一个跨站HTTP请求的时候，***者可以在请求里用Flash Player来设置Origin字段。在处理跨站请求的时候，token验证的方法处理的不好，因为token会暴露。为了应对这些***，网站不应当接受不可信来源的跨站请求。
4、应用。Origin字段跟以下四个用来确定请求来源的建议非常类似。Origin字段以下四个建议的基础上统一并改进了，目前已经有几个组织采用了Origin字段的方法建议

$allow_origin = array(
    'http://zbvd.com',
    'http://sc.com',//将商城域名配置到此处跨域处理
    'http://svideo.55jimu.com',
);
if(isset($_SERVER['HTTP_ORIGIN']) && in_array($_SERVER['HTTP_ORIGIN'], $allow_origin)){
    // 指定允许其他域名访问
    header('Access-Control-Allow-Origin:'.$_SERVER['HTTP_ORIGIN']);
    header('Access-Control-Allow-Credentials:true');
// 响应类型
    header('Access-Control-Allow-Methods:POST');
// 响应头设置
    header('Access-Control-Allow-Headers:x-requested-with,content-type');
}