可能重复：
如何知道表格的来源？
我今天浏览了这些论坛，但我找不到一个足够好的答案来回答我的问题。
如何停止将表单提交到我的服务器，除非它们被从我的域引用。我已经意识到，如果有人直接复制我的表单HTML并将其粘贴到他们自己的平台上，他们表单中的数据将解析我的文件，并执行表单在我的网站上设置的操作。
我该如何防止这种情况发生？我想检查一下推荐人是否来自我的域名，但根据我的研究，这不会阻止这种情况的发生。那么我该如何阻止这种情况的发生呢？
REFERER很容易被欺骗，但很容易检查，因此作为主要的防御屏障，它还不错。为了进行更复杂的预防，您可以在加载具有相关表单的页面时生成令牌，将其存储在用户会话中，将其保存在表单的隐藏字段中，并在提交表单时根据会话值进行检查。不过，如果有人愿意，也可以绕过它，所以根据你的具体情况，HTTPS将是最后的手段。
您可能试图防御两种类型的攻击。
第三方欺骗用户在您的网站上执行操作
这是Alice登录Bob的网站，然后访问攻击者的网站，攻击者的网站导致Alice的浏览器向Bob的网站发出（例如）"转账"请求。
这是一种CSRF攻击，标准防御是在隐藏字段中包含用户会话中也存在的令牌。
攻击者无法将令牌放入他们的表单中，因此如果令牌匹配，您就知道表单在您的网站上。
用户修改表单中的数据以提交一些他们不应该提交的数据
例如，Alice在提交编辑请求之前更改了评论的POST_ID，从而编辑了其他人的帖子，或者她可能更改了所订购商品的价格。
对此的防御措施是验证输入。如果收到编辑请求，请确保登录用户具有编辑帖子的权限。如果收到订单，那么只需注意商品ID和数量，就可以从数据库中获得价格。等等
您不能依赖referrer！它可以被禁用。
但是您可以使用token，您可以将其a）写入隐藏的输入字段，b）写入用户的会话。在您的目标脚本中，您只需检查它们是否等效！
您试图确保当POST进入应用程序时，它来自服务器的FORM，而不是其他地方。这被称为跨站点请求伪造（CSRF）攻击。
检查推荐人有问题。首先，HTTP规范特别允许客户端不发送引用字符串（出于各种隐私原因）。因此，你的一些客户端可能不包括它。其次，引用字符串可能会被欺骗，有足够技能的攻击者可以让它们看起来像他们需要的样子，以成功实施CSRF攻击。
使用CSRF验证令牌是一种更强的方法，也是抵御CSRF攻击的首选方法。您可以在OWASP CSRF备忘单上阅读为什么会出现这种情况。
我还要指出，你没有理由不能两者兼而有之。深度防御（DiD）策略通常是可取的，因此攻击者需要击败多个独立的防御才能成功执行攻击。您可以实现弱引用人检查方法（如果引用人是由客户提供的，请在对请求采取行动之前确保它是应该的；如果引用人不存在，请像它存在并正确一样进行）以及CSRF验证令牌。这样，如果客户端在使用更强的验证令牌方法的同时提供了引用的信息，则可以检查该信息。