前端用 VUE3 打包静态文件，后端 API 是否需要考虑安全保护？

[fox0001]

本人前端小白。

体验过 VUE3 后，确实很爽。但是打包成静态文件后，后端 API 就不能限制客户端访问了。访问 API 时，设置请求头、生成签名、加密规则等，都等于赤裸裸地暴露出来。

疑问：

1. 大家是怎样保护后端 API 的？我知道 API 暴露出来，就不能 100%防止恶意访问或者伪装客户端，但至少提高一下门槛吧？

2. 会不会是我多虑了？既然是暴露出来的 API ，就不用考虑伪装客户端的问题？限制 API 访问频率，应该是基本的设置。

3. 又或者说，如果是需要较高安全级别的 API ，就不应该采用这种静态文件的访问方式？

4. 这个问题，是不是应该发到后端那边去讨论？😂

[233373]

SSR

[fox0001]

@233373 #1 采用 SSR 的话，就是问题 3 ，不要使用这种静态文件访问，即 CSR 。对吧？

[hackyuan]

你们接口没有认证（权限）的吗？

[fox0001]

@hackyuan #3 手机项目的接口有认证。只是我好奇，如果 web 项目（特别是不需要登录的页面）采用这种方式实现，认证要怎么做？如果认证方式都通过 JS 实现，可以看到源码，是不是等于没认证？

[cxe2v]

认证所需要的令牌是登陆时候服务器生成并下发的，验证过程也是在服务端，前端只能看到发送的代码，并没有什么影响

[MonoLogueChi]

1. 权限较高的接口需要登录和鉴权
2. 公开接口可以只做 host 认证，特殊一点的可以生成令牌，这类接口暴露也无所谓

[fox0001]

@cxe2v #5 应该分两个方面来看吧。

根据用户认证而发放令牌去访问接口，这种认证方式没问题。

但是如果我想根据客户端限制访问 API （或者提高伪装客户端的门槛），这种认证是否就不可行？

手机的话，起码可以采用客户端 key 、可以生成签名之类鉴别是来源手机客户端（虽然可以反编译）。打包静态文件，都是 JS 代码，就不能这样玩了吧？

[fox0001]

@MonoLogueChi #6 明白，谢谢～

但是我想确认一下，是不是采用 CSR ，就不能限制访问 API 的客户端？就是默认允许客户可以通过我们打包的静态文件、curl 、postman 等方式访问相关 API ？

[cxe2v]

@fox0001 VUE 编译后的 js ，是经过压缩和混淆的，正常来说，打开之后人类非常难识别，所以你担心被看到源码，其实跟你所说的需要反编译才能看到一些东西一样有门槛

[fox0001]

@cxe2v #9 谢谢！因为我入门 VUE3 时，是手写 JavaScript ，所以有这样的疑问。

[LeeReamond]

@cxe2v vue 什么构建工具自带混淆？ vite 有吗，我质疑

[cxe2v]

@LeeReamond https://vitejs.bootcss.com/config/#build-minify

[wenzichel]

当前端发布出去后，其实接口就基本已经暴露了。若使用 SSR 这种服务端渲染方案，虽然接口没有暴露出来，但羊毛党也可以直接模拟浏览器的情况，来假装是一个正常用户，不再关心你的接口具体是什么。

前端能做的工作很少，大部分都得后端的一些防护策略。简单说下我们这里的限制策略：

1. 登录态；在该用户已登录时，可以限制其某一接口、奖励等各种频次，限制奖励的上限等；
2. 我们有些接口会通过原生客户端访问后端接口，这里可以客户端的代理请求，客户端在这个请求中加上 token ，后端再用相同算法加密出一个 token ，然后进行对比；不过原生客户端可能也会被逆向，加密算法就暴露了，但也增加了破解成本；
3. 风控，通过该用户一系列的行为，判断该账号是否是可疑账号；

[kingjpa]

其实不管你用不用 vue ， 只要和 api 有交互， 请求在客户端本地都是透明的。 浏览器调试工具就可以看到。

关键还是在服务端做好 限流 认证 等操作。

[daliusu]

没明白这个问题，你就算页面不报漏出去，别人抓包不还是能抓到你接口？ ssr 也不能解决这个问题啊，因为 ssr 后续页面还是前端 ajax 拉请求。你为了安全你加验证做权限管控不就行了么。我觉得做混淆也是走了歪路（虽然也应该做，毕竟成本不高），因为你代码放出去就要做好被人拉到完整包的准备， 不能寄希望于混淆了别人就搞不清你的逻辑了。另外包括你说的限制客户端啥的，只能提高别人搞你的难度，因为他完全可以自己编译一个浏览器出来，你怎么都防不了的，我建议从需求去考虑这个事情，是否真的有这个需求

[dcsuibian]

要考虑。不过不是前端考虑。
所有前端发过来的东西都是不可靠的。敏感数据鉴权，限制访问次数都是后端的事。
前端做不了，浏览器控制台看网络请求，api 一目了然。你要回避就得在请求体里再加密包一层，但前端加密的密钥还是藏在前端代码里的。

有些网站，比如 github 、v2ex 还会提供开放 api ，允许别人直接访问。这时候连前端都没有。
代码混淆什么的可以做，不过得在后端已经做得很安全了以后，锦上添花罢了。

最后，打开你平时上的网站：百度、狗东、B 站、支付宝，甚至是竞争对手的网站，看看人家咋做的。

[janus77]

1.前端有 混淆加密等常规措施，和 app 一样。通用的措施还有 加权限校验等，也是和 app 一样。主要的门槛还是由后端来做，前端做不了太多，做好常规的就可以了
2. 确实是多虑了，但是问题不在这里，因为除去基本的防护以外，这部分工作主要不是由前端承担的
3. 访问方式不管什么安全级别都没有区别，主要是在访问的流程上加限制，进行过滤
4. 你说对了，就是需要后端来做

[darknoll]

难道楼主不会用浏览器的 F12 ？

[shadowfish0]

感觉楼主问的是 deepL 那种翻译软件的应用场景吧，收费提供 API ，又同时提供无登录态的免费 web 翻译服务。之前读过一篇文章专门分析 deepL 网页翻译 API 的发起思路，总的来说其实还是通过混淆+代码故意写的让你想不到那个加密逻辑，没办法彻底防止是肯定的，不过通过一些奇淫巧计让破解者痛苦还是挺有用的，毕竟接口都不需要登录态了，应该也不太重要

[fox0001]

@darknoll #18 这样说吧。大家都知道没有百分百安全的门锁，但是上班前还是会锁上家门