始终假定对手具有对浏览器的完全控制权。
通常,如果您希望自己的应用程序免受恶意实体的侵害,则它的安全性必须来自服务器。制作可以由您的服务器验证的授权/承载令牌或cookie方案(即https://jwt.io/)。然后,仅允许根据该信息将数据发送到想要的用户。前端的安全性/验证更多是关于确保用户不会无意间弄乱事情。
用户具有通过各种开发工具修改浏览器中任何HTML / CSS / JS的能力。
用户具有通过JavaScript发送的所有信息的完全访问权限(即使信息被缩小了,也有一些工具可以在某种程度上使信息最小化)。
使用React的开发工具可以轻松修改所有React状态。如果您使用的是redux,则可以设置redux开发工具。
在Firebase中,文档中有整个section on security。设置RestrictedView
后面的数据,以要求您需要它们进行身份验证。确保Firebase做到了应用程序安全性的共享。 section on insecure rules也是开始阅读Firebase可以为您做什么以及如何configure their security rules的好地方。
一些进一步的阅读:
OWASP Top Ten (2017) Broken Access Control(为强调起见,添加了粗体)
访问控制仅在受信任的服务器端强制实施时才有效
代码或无服务器API,攻击者无法在其中修改访问权限
控制检查或元数据。
-
除公共资源外,默认情况下拒绝。
-
实施一次访问控制机制,并在整个应用程序中重复使用它们,包括最大程度地减少CORS的使用。
-
模型访问控制应强制执行记录所有权,而不是接受用户可以创建,读取,更新或删除任何内容
记录。
-
唯一的应用程序业务限制要求应由域模型强制执行。
-
禁用Web服务器目录列表,并确保Web根目录中不存在文件元数据(例如.git)和备份文件。
-
记录访问控制失败,并在适当时提醒管理员(例如重复失败)。
-
速率限制API和控制器访问权限,以最大程度地减少自动攻击工具带来的危害。
注销后,-
JWT令牌应在服务器上失效。开发人员和质量检查人员应包括功能访问控制单元和集成测试。
Understanding React Frontend security
我们需要澄清一件事-您放入客户端的所有内容
客户端可以轻松更改浏览器。
该文章后面:
如何防止用户访问我网站的非公开部分?
您完全按照自己的方式进行操作-创建变量,设置
仅对管理员有效,一旦检查通过,请显示管理员
唯一的内容。
“好吧,那一点也不安全-每个人都可以进入管理页面
并删除所有内容!”你尖叫。
一般-但仅当您以不良方式实施应用程序时。的
前端部分不应该关注有效性
提供的凭据。它应该始终接受数据为“ true”,并且
只需渲染所有传递的数据即可。
这是执行此验证的后端工作!
本文链接:https://www.f2er.com/2267725.html