为啥用 F12 看不到很多公司的接口请求和响应的？请问下大家这种具体是怎么做到的？

[shadow1949]

对网络传输和安全这一块不太了解，最近公司让我们对接口出入参做个加解密，我便想去其他平台看看他们怎么做的，发现很多页面实际上都无法抓到实际的 XHR 接口，要么返回的是整个页面，要么直接在网络里面啥都找不到……

请问下大家这种具体是怎么做到的？是直接存在 CDN 之类的里面吗(可应该不会所有页面都在 CDN 吧)？

另外有必要对接口出入参做加解密吗？搜了一些文章，有些人说可以用 RSA 和 ASE 做加密，有些人又说出入参加解密根本没必要，因为 HTTPS 本身够安全，即使加密，前端代码也是公开的，能够直接破解。

[rqxiao]

前端有代理服务器

[Moyyyyyyyyyyye]

服务器渲染做的

[flyqie]

给个地址？

真实请求无法隐藏。

[dapang1221]

websocket
quic
或者压根就是上古 MVC 架构服务器直接渲染出来的 - -

[NelsonZhao]

统一这个观点：因为 HTTPS 本身够安全，即使加密，前端代码也是公开的，能够直接破解。
建议问一下领导出入参加密的原因是啥。

[flyqie]

@NelsonZhao #5

网易云游戏加密了。。

好奇为啥要加密。

[Puteulanus]

你是不是遇上 SSR 的了，server side rendering
接口感觉一般是做签名，签名的函数再给混淆一下，防止用户模拟和重放

[clue]

服务端渲染直出, websocket

websocket 想要抓包, 得在一开始就打开 dev 面板, 在建立连接时抓到

另外对外开放的 API 一般不做加密(HTTPS 本身就够了)只做签名, 用于防重放/篡改, Timestamp+Nonce+Signature

[corcre]

MVC 可以做到, 也有可能是更远古的 PHP 混编整出来的🐶

[flyingghost]

https 只保护传输不被监听、窃取、篡改。
也就是客户端和服务器之间不会蹲有一个未知的“中间人”。
但客户端本身就是一个攻击面。如果客户端不安全，相当于一个逆向工程师蹲在浏览器里，所有输入、输出、渲染过程、前端交互逻辑、渲染数据都失密。
好在以上大部分都不怎么值钱，值钱的都服务端计算/渲染了。
唯一值钱的是当前账号个人数据，系统风险可控，法律风险更好甩，反倒是防护成本巨高效果不好，就这样吧。

[sniperhgy]

现在有一些网站，也会专门针对“开发者模式”进行阻挠，之前想在一个外国的 online game 网站上用 F12 找到真正的游戏 rom 地址，结果直接就告诉我侦测到开发者模式，不能进行后续操作😂

[zorro2020]

还遇到一些 APP 正常可以访问，手机一连代理，APP 就网络异常，什么请求都看不到了

[dyllen]

曾经面试遇到面试官说 post 比 get 更安全，因为 get 参数放到 url 里面可以在地址栏直接复制。。。

[dyllen]

@zorro2020 这种应该是做了双向证书验证吧？

[SoyaDokio]

“开发者工具” 的 “网络监控” 里开启监控功能后看不到请求记录？？
这个也行？有啥意义呢，抓包也都可以拿到阿？
应该是我理解错了吧

[shadow1949]

@Puteulanus
应该是 SSR ，之前只尝试打开一些网页，看不到正常出入参的接口感觉很奇怪。

现在重新去试了一些新增更新操作，发现 GET 请求基本都是返回页面，然后 POST 请求能够正常看到入参和出参的。

[me1onsoda]

@NelsonZhao 增加破解成本，提高破解门槛

[blackcellcode]

SSR

[error451]

https 可以防止中间人获取请求数据内容来进行中间人攻击。

对参数进行加密，目的是为了防止参数篡改重放， 就是攻击者修改原来的参数再次请求。

这两个安全措施的目的并不一样啊。

如果 API 加了安全令牌，时间戳等防重放的安全措施，则就没必要再对参数整体加密了。

[cxe2v]

@dyllen #13 是的，至少 post 要打开 F12 控制台，比地址栏复制多两步

[lm930129]

参数加密确实没啥用，因为你肯定有个前端解密的过程，你前端代码是没法加密的。比如，某政府网站，接口通过物理 key 进行加解密，传出和传入参数都是密文，但是意义不大的，你在控制台，直接调用前端加密和解密函数，就可以得到明文的。

[datoujiejie221]

现在单一的加解密已经很难防止破解了，看了 https 协议，你会发现最复杂的不是加解密，而是双方随机数的生成，就像 gpt 和文心一言网页版，虽然请求可以抓到明文，但是随机 token 的生成几乎不能破解。

[F7TsdQL45E0jmoiG]

前后端分离天生就不安全

[ljsh093]

ws 传输的吧

[Light3]

十年前的模版渲染？

[lyc8503]

可能性:
1. 使用了模板渲染
2. Websocket
3. Server-side rendering

解决方法:
1 直接用 bs4 解析 html 拿数据
2 直接看 Websocket
3 可以直接读取 __NEXT_DATA__

如果要接口加密，自己 JS 写个签名算法，混淆 JS 能提升逆向难度，但也是治标不治本，有经验的人来很快就能分析出来

正确方法是后端进行风控，比如限制手机号登录，限制 IP 等

[sampeng]

https 没必要把接口做加密。直接做签名就好了。签名包含时间。后端就能做风控了

[xiangyuecn]

万物皆可破解，就看值不值

[Nosub]

首先要说的是安全只是相对的，后端渲染和 socket 本身也有自己的局限性，数据全部加密不是不行，成本太高，前后端都要加解密，@sampeng 这个哥们说的基本是对的，如果网站本身已经是 https 了，做 api 的接口签名校验就可以了，敏感的数据还是要加密的，比如注册，登陆时候的账号密码，刚好我最近写了一篇文章，感兴趣的可以看看，https://nosub.net/posts/p/72

[kahlkn]

前端加密只能防止一些门外汉（不过像登录账号密码等，可以考虑加个密）。 专心搞破解的，前端加密没啥用。

你说的那种抓不到 xhr ，大概率两种，一种就是服务端 渲染成 Html 直接到浏览器（比如 nodejs 服务端 和 古早的模板引擎）。 还有一种就是它走的是 JS ，再 某个 JS 文件中包含了数据，然后渲染到前端界面。

[gitlight]

可能做 SSR 了

[rockyliang]

@Nosub #29 ，文章里的 HTTPS 加解密流程图已经过时了，现在的 HTTPS 基本上都是使用 ECDHE 密钥交换协议，服务器的公钥每次都是随机生成的，并不会使用证书里的公钥来加密 AES 密钥

[Promtheus]

很有可能是因为他请求的后台接口应用不是你前段看到的这个应用，是一个独立的应用。这样你就 f12 看不到了。抓包才可以看到