几乎所有关于反CSRF机制的文档都声明应该在服务器端生成CSRF令牌。不过，我想知道是否有必要。是否需要在服务器端生成反XSRF/CSRF令牌？
我想要实现反CSRF在下列步骤操作：
没有服务器端生成的CSRF令牌;
在浏览器端，在每个AJAX或表单提交中，我们的JavaScript会生成一个随机字符串作为标记。在实际的AJAX或表单提交发生之前，该令牌被写入cookie csrf;并将令牌添加到参数_csrf。
在服务器端，每个请求都应该有饼干CSRF，并提交论证_csrf。这两个值进行比较。如果它们不同，则意味着它是CSRF攻击。
服务器端并不需要发出CSRF令牌，只是做了检查;并且令牌在浏览器端完全生成。当然，这只是针对反CSRF。在服务器端应该有认证过程来验证用户ID。
这听起来是CSRF的有效解决方案，但我不确定为什么没有关于此方法的文档。
这个反CSRF机制有什么错吗？
据我所知，你想要做的是在客户端创建你的反CSRF，将它存储在一个cookie中，并将它作为请求参数添加，所以当服务器读取你的请求时，只需要验证您的CSRF令牌cookie和参数是否匹配，并确定它是否是有效的请求。
在服务器端生成反伪造令牌的原因是，服务器将创建该令牌，并且只有服务器才知道正确的值，所以如果该参数在客户端有轻微的篡改，它会与存储在服务器中的不一样，并且足以将该请求标记为跨站点请求伪造攻击。 任何客户端生成的数据都可能被攻击者篡改，因此，您不能依赖该信息，例如，在您的方法中，您在客户端创建一个随机值，并将该值分配给您的CSRF cookie和您的_csrf参数，假设您的值为“h246drvhd4t2cd98”，但由于您只验证客户端的2个变量具有相同的值，因此攻击者可以轻松创建CSRF Cookie和变量像他们和你的服务器上的“I'mByPassingThis”这样的值会将其标记为有效请求，所以你根本没有获得安全性。另一方面，如果在服务器中生成令牌，攻击者无法知道期望值，并且每个请求的值都不相同，所以攻击者的最佳方法就是试图猜测它，这实际上是不可能的，除非你在服务器端使用可预测的随机数生成器。另外，如果你想创建自己的反伪造令牌机制，你需要考虑使用一个密码安全的伪随机数发生器，但老实说，你不应该打扰，因为当前的服务器 - 生成过程就是你所需要的（假设你的框架有一个内置的机制，如果没有的话，那么你仍然需要确保你使用了一个密码安全的伪随机数生成器来生成你的防伪标记）。
切记不要信任用户提交的信息。由于它总是可以被篡改，因此您总是需要在服务器端执行一次双重检查，在这种情况下，在服务器中生成您的防伪标记可以让您仔细检查以验证提交了反伪造令牌。