我将首先解释“后端控制”和“前端控制”的含义。
我用php框架开发了多年的Web应用程序。它始终与php后端处理所有逻辑并将“视图”发送给客户端。这就是我所说的“后端控制的Web应用程序”。
现在我理解了我所谓的“前端控制应用程序”的关注点分离的优势，后端从不将html视图发送给客户端。它只发送数据，视图完全由客户端处理（angularjs，vuejs，...）。这允许移动应用程序最终也使用相同的后端（现在只是一个REST API）。
所以现在我通过“后端控制的Web应用程序”和“前端控制的Web应用程序”解释了我的意思，并解释说我了解前端控制的Web应用程序的一些优点。现在我要提一下我对这方面的疑虑，我期待这些疑惑的答案，因为我确信有些答案我不知道：
在后端控制的Web应用程序中，表单受跨站点请求伪造保护（至少在您使用体面的后端框架时）。在场景后面，会话中添加了一个令牌，以确认该请求来自同一个申请表。你如何在前端控制的应用程序中做到这一点？
我见过前端控制的应用程序对同一页面发出多个请求（一个请求身份验证，一个请求每个组件（比如网页的部分））。另一方面，我们知道“浏览化”我们的资产（css和js）以减少对服务器的请求数量是一个好习惯。因此，一方面尽可能少地向后端发出请求是一种很好的做法，但另一方面，对于前端控制的应用程序，通常会看到一个页面有5个请求，例如后面的-结束。如果它是一个后端控制的应用程序，那么同一页面只需要1个请求。
由于
答案 0 :(得分：0)
我再次对csrf和IIUC进行了研究，从那以后XHRs对抗csrf更好：
origin标头添加到所有XHR，这会阻止来自意外域的所有请求（以及服务器端的allow-origin配置）。我们可以通过在服务器端渲染页面时手动将csrf令牌添加到js代码来做更多事情（稍后将在XHR中发送请求）。攻击者无法获取js代码中的令牌。 编辑：这对于单页应用并不是唯一的，我了解到传统的服务器渲染网站可以通过在阅读{{1}后在表单的隐藏字段中编写令牌来做同样的事情} wikipedia的章节。而不是Synchronizer token pattern，我想到<input type="hidden" name="csrftoken" value="..." />（<script>var csrfToken={{server.token()}}</script>是服务器端模板）。在发布表单时使用前者，在js代码发送XHR时使用mine。我的想法是维基百科页面中{{}}章及其下一章的混合。通过这些方法，如果我们的站点没有XSS，攻击者将无法在session / page / js中获取令牌，并且他欺骗用户的浏览器发送的请求将在没有令牌的情况下失败。
这导致：现代单页应用程序比传统的Web应用程序XHR 更重，传统的Web应用程序利用js操纵的视图更改（使用XHR）在不同场合使用整页服务器端呈现。因此，更安全。
1请求绝对优于5，如果只是为了请求计数。在这里我们进行权衡：通过添加一些流量来加载页面，我们得到：
更好地分离前端和后端的顾虑。后端开发人员编写较小的单功能接口。对于前端开发人员来说更好：视图，样式，交互逻辑脚本（我们可以在Synchronizer token pattern文件中看到）都是按组件组织的，更少的事情需要担心，我们可以更快乐。
因此，我认为交易是完全值得的。