前端用 VUE3 打包静态文件，后端 API 是否需要考虑安全保护？
fox0001 · 2022-07-16 08:58:47 +08:00 via Android · 3291 次点击这是一个创建于 894 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人前端小白。
体验过 VUE3 后，确实很爽。但是打包成静态文件后，后端 API 就不能限制客户端访问了。访问 API 时，设置请求头、生成签名、加密规则等，都等于赤裸裸地暴露出来。
疑问：
-
大家是怎样保护后端 API 的？我知道 API 暴露出来，就不能 100%防止恶意访问或者伪装客户端，但至少提高一下门槛吧？
-
会不会是我多虑了？既然是暴露出来的 API ，就不用考虑伪装客户端的问题？限制 API 访问频率，应该是基本的设置。
-
又或者说，如果是需要较高安全级别的 API ，就不应该采用这种静态文件的访问方式？
-
这个问题，是不是应该发到后端那边去讨论？😂
 |
1
233373 2022-07-16 09:03:42 +08:00
SSR
|
 |
2
fox0001 OP @233373 #1 采用 SSR 的话，就是问题 3 ，不要使用这种静态文件访问，即 CSR 。对吧？
|
 |
3
hackyuan 2022-07-16 09:25:58 +08:00
你们接口没有认证（权限）的吗？
|
|
4
fox0001 OP @hackyuan #3 手机项目的接口有认证。只是我好奇，如果 web 项目（特别是不需要登录的页面）采用这种方式实现，认证要怎么做？如果认证方式都通过 JS 实现，可以看到源码，是不是等于没认证？
|
 |
5
cxe2v 2022-07-16 09:40:24 +08:00
认证所需要的令牌是登陆时候服务器生成并下发的，验证过程也是在服务端，前端只能看到发送的代码，并没有什么影响
|
 |
6
MonoLogueChi 2022-07-16 09:51:00 +08:00 via Android  1
1. 权限较高的接口需要登录和鉴权
2. 公开接口可以只做 host 认证，特殊一点的可以生成令牌，这类接口暴露也无所谓 |
|
7
fox0001 OP @cxe2v #5 应该分两个方面来看吧。
根据用户认证而发放令牌去访问接口，这种认证方式没问题。 但是如果我想根据客户端限制访问 API （或者提高伪装客户端的门槛），这种认证是否就不可行？ 手机的话，起码可以采用客户端 key 、可以生成签名之类鉴别是来源手机客户端（虽然可以反编译）。打包静态文件，都是 JS 代码，就不能这样玩了吧？ |
|
8
fox0001 OP @MonoLogueChi #6 明白，谢谢～
但是我想确认一下，是不是采用 CSR ，就不能限制访问 API 的客户端？就是默认允许客户可以通过我们打包的静态文件、curl 、postman 等方式访问相关 API ？ |
|
9
cxe2v 2022-07-16 10:31:05 +08:00 1
@fox0001 VUE 编译后的 js ，是经过压缩和混淆的，正常来说，打开之后人类非常难识别，所以你担心被看到源码，其实跟你所说的需要反编译才能看到一些东西一样有门槛
|
|
10
fox0001 OP @cxe2v #9 谢谢！因为我入门 VUE3 时，是手写 JavaScript ，所以有这样的疑问。
|
 |
11
LeeReamond 2022-07-16 11:11:27 +08:00 via Android
@cxe2v vue 什么构建工具自带混淆？ vite 有吗，我质疑
|
|
12
cxe2v 2022-07-16 11:18:04 +08:00
|
 |
13
wenzichel 2022-07-16 11:29:09 +08:00
当前端发布出去后，其实接口就基本已经暴露了。若使用 SSR 这种服务端渲染方案，虽然接口没有暴露出来，但羊毛党也可以直接模拟浏览器的情况，来假装是一个正常用户，不再关心你的接口具体是什么。
前端能做的工作很少，大部分都得后端的一些防护策略。简单说下我们这里的限制策略： 1. 登录态；在该用户已登录时，可以限制其某一接口、奖励等各种频次，限制奖励的上限等； 2. 我们有些接口会通过原生客户端访问后端接口，这里可以客户端的代理请求，客户端在这个请求中加上 token ，后端再用相同算法加密出一个 token ，然后进行对比；不过原生客户端可能也会被逆向，加密算法就暴露了，但也增加了破解成本； 3. 风控，通过该用户一系列的行为，判断该账号是否是可疑账号； |
 |
14
kingjpa 2022-07-16 11:39:15 +08:00
其实不管你用不用 vue ， 只要和 api 有交互， 请求在客户端本地都是透明的。 浏览器调试工具就可以看到。
关键还是在服务端做好 限流 认证 等操作。 |
 |
15
daliusu 2022-07-16 11:42:11 +08:00
没明白这个问题，你就算页面不报漏出去，别人抓包不还是能抓到你接口？ ssr 也不能解决这个问题啊，因为 ssr 后续页面还是前端 ajax 拉请求。你为了安全你加验证做权限管控不就行了么。我觉得做混淆也是走了歪路（虽然也应该做，毕竟成本不高），因为你代码放出去就要做好被人拉到完整包的准备， 不能寄希望于混淆了别人就搞不清你的逻辑了。另外包括你说的限制客户端啥的，只能提高别人搞你的难度，因为他完全可以自己编译一个浏览器出来，你怎么都防不了的，我建议从需求去考虑这个事情，是否真的有这个需求
|
 |
16
dcsuibian 2022-07-16 12:23:02 +08:00
要考虑。不过不是前端考虑。
所有前端发过来的东西都是不可靠的。敏感数据鉴权，限制访问次数都是后端的事。 前端做不了，浏览器控制台看网络请求，api 一目了然。你要回避就得在请求体里再加密包一层，但前端加密的密钥还是藏在前端代码里的。 有些网站，比如 github 、v2ex 还会提供开放 api ，允许别人直接访问。这时候连前端都没有。 代码混淆什么的可以做，不过得在后端已经做得很安全了以后，锦上添花罢了。 最后，打开你平时上的网站：百度、狗东、B 站、支付宝，甚至是竞争对手的网站，看看人家咋做的。 |
 |
17
janus77 2022-07-16 13:18:07 +08:00 1
1.前端有 混淆加密等常规措施，和 app 一样。通用的措施还有 加权限校验等，也是和 app 一样。主要的门槛还是由后端来做，前端做不了太多，做好常规的就可以了
2. 确实是多虑了，但是问题不在这里，因为除去基本的防护以外，这部分工作主要不是由前端承担的 3. 访问方式不管什么安全级别都没有区别，主要是在访问的流程上加限制，进行过滤 4. 你说对了，就是需要后端来做 |
 |
18
darknoll 2022-07-16 18:55:26 +08:00
难道楼主不会用浏览器的 F12 ？
|
 |
19
shadowfish0 2022-07-16 22:35:37 +08:00
感觉楼主问的是 deepL 那种翻译软件的应用场景吧，收费提供 API ，又同时提供无登录态的免费 web 翻译服务。之前读过一篇文章专门分析 deepL 网页翻译 API 的发起思路，总的来说其实还是通过混淆+代码故意写的让你想不到那个加密逻辑，没办法彻底防止是肯定的，不过通过一些奇淫巧计让破解者痛苦还是挺有用的，毕竟接口都不需要登录态了，应该也不太重要
|
|
20
fox0001 OP @darknoll #18 这样说吧。大家都知道没有百分百安全的门锁，但是上班前还是会锁上家门
|
Select Language