Security SPA架构问题

这篇文章的目的是开始一个关于web单页应用程序的更深入的讨论。在关于这个主题的大多数资源中，有些问题似乎没有明确的答案。 它们在我的脑海里

授权和认证。 由于整个web应用程序都在客户端上，它可能会调用服务器的任何功能，甚至是用户无权调用的功能。用户看不到菜单这一事实并不妨碍该用户调用java脚本函数。这在MVC应用程序中很容易处理，例如，通过使用基于cookie验证特定功能的用户权限的控制器。然而，一些SPA应用程序只使用带有Breeze或Web Api的单一控制器，这使得授权服务器端变得不可能

客户机上的内存管理 对于小样本应用程序来说，这不是一个问题，但是想象一下，一个应用程序有100个屏幕，或者一个应用程序有一个单一的屏幕，在一天的时间内提取数千条记录。有了持久缓存，人们可以想象出巨大的内存问题，特别是在诸如手机或平板电脑等内存不足的设备上。如果没有处理内存管理的清晰愿景，一组开发人员怎么可能有SPA路线

三层部署 一些IT部门永远不允许应用程序使用连接字符串访问位于前端web服务器上的数据库。我看到的每一个SPA演示都是这样的结构，包括Breeze或WebAPI

不引人注目的验证。 它将要求开发人员使用MVC局部视图和控制器，而不仅仅是HTML文件，这似乎与SPA概念背道而驰，同时它提供了一种非常健壮的方法，可以轻松地将验证和UI合并到web应用程序中，以支持它

在url中公开基于主整数的键。
这在OWASP中不是no。 因此，SPA应用程序“似乎”针对的是安全需求很少、功能集较小的领域。你觉得怎么样

---

谢谢。

@Sergey-我觉得这个问题对StackOverflow来说太宽泛了。S.O.不是一个讨论论坛；这是一个寻找具体答案的地方。所以，虽然你们的问题可能是正确的，但我认为你们不应该对这里的深入实质性回答抱有太多希望

请允许我以最友好的方式补充一句，你那笼统、不受支持和消极的言论让你看起来像个巨魔。你不是巨魔，是吗，谢尔盖

有可能你真的很关心，我提供一些快速的反应，特别是当它们与微风有关时

授权。在Web API中，您可以在方法级别进行授权。ApicController基类有一个

User

属性，返回

IPrincipal

。因此，无论您有一个控制器还是多个控制器（如果需要，您可以在Breeze中有多个控制器），粒度都是方法级的，而不仅仅是类级的

内存管理。桌面开发人员多年来一直在应对这一问题。如果您一直开发流程生命周期很短的传统web应用程序，这可能会让您感到惊讶。但对于我们这些使用WinForms、WPF和Silverlight等桌面技术构建大型应用程序的人来说，长时间运行的流程并不新鲜。在HTML和JavaScript领域，问题和解决方案基本相同

后端上的层。你看演示的时间太长了。是的，大多数演示都会将所有内容转储到一台服务器上运行的一个项目中。我们假设您知道如何重构服务器以满足环境的可扩展性、性能和安全性要求。我们的演示主要关注前端水疗开发。我们确实涉猎了服务边界，以展示数据是如何通过服务API、ORM和数据库流动的。我们认为识别这些不同的层就足够了，把把把这些层移动到不同的层作为一个练习留给读者。有一天我们可能不得不重新审视这一假设。但是，有人真的认为在服务器端层之间分配层/职责存在重大障碍吗？真正地像什么

不引人注目的验证。当大多数人开始在HTML中使用“unobtrusive”这个词时，他们通常会强调将JavaScript排除在HTML之外。也许这也是你的意思，在这种情况下，各地的水疗开发商都同意。。。这就是为什么有许多“不引人注目的验证”库可用的原因。HTML5验证、jQuery验证和敲除验证浮现在脑海中。所有这些都在SPA开发者工具包中，没有一个“要求开发者使用MVC局部视图和控制器”。什么给您的印象是SPA需要任何类型的服务器端资源来实现无JavaScript HTML标记的验证

作为安全风险的Ids。真正地这是假的。密钥值与任何其他数据值一样，都不存在安全风险。数以百万计的应用程序——不仅仅是SPA——在URL和正文中向客户端传递键值。它是RESTAPI中的标准。这是小田的标准。你想通过说它们“针对安全要求很少、功能集很小的领域”来否定它们吗？祝你好运。我认为你必须做得更好，而不是把你的案例放在一个相对模糊的组织的整个网站的链接上

---

我已经构建了一些SPA应用程序，从小到大（超过100个脚本和视图）。只有极少数人能看到公众可以看到的所有景色。其余的通过严格的访问结构。从服务器返回未经授权的401，而客户端只是处理401，将其重定向到登录屏幕，这非常简单。沃德先生和爸爸先生纠正了这一点。退出演示模式并重新启动