后端表示参数拼接成 SQL 接收，真的服了，就不怕 SQL 注入抗投诉服务器吗

复制黏贴，能跑就行

2021 年了为啥还有程序员天天编程写 bug 啊?

常见的安全问题都不 care 吗

2B 的产品有时候 sql 拼接参数是 feature

你去看看事业单位用的办公系统

后端校验啊。 前端只有约定好格式就行。和前端有什么关系。 你只要约定好 前端 delete 。后端当 select 用也行啊

sql 作为描述语言，谁规定一定就是用来操作数据库的？用来操作搜索引擎不可以吗？

sql 和前端有毛的关系

还真有，那个前两年兴起的前端 sql 技术，后端只需要约定接口通往数据层的表模型，前端自己调 sql 读写，我忘记叫什么了。 我一直觉得不靠谱……

我记得 老项目 CS 架构的 都是 直接客户端传 SQL，
服务端搞个 sql parser 就知道这条客户端提交的 sql 是否有权限。

https://data.stackexchange.com/
https://www.opendota.com/explorer
不怕注入吗？
这也不是前端，这是 API 。同样一个 HTTP API，另一个后端程序也可以调用。
前端是 UI 到 API 中间的东西（不管它的技术手段是啥）

https://carto.com/
这个公司为每个用户新建一个数据库

怕什么注入, 法院重拳出击就行了

这能怪前端？？你后端干嘛吃的

现在有种东西叫 graphql，类似

能这么做的项目显然确实没啥用户量，甚至说是自己给自己用。对于注入这种事，小公司不遇到是不会去防的

老板：又不是不能用

你是想说 graphQL 么，这个可跟直接拼 SQL 不一样哦

老板：能用为啥还这么讲究？

告诉各位我曾经呆过的某公司，近两年做的一个模块，名曰 xxx risk analysis，
卖点是分析业务相关的指标和风险点，具体怎么做的呢？
业务人员默认准备了一堆 SQL，可以根据需要在页面上微调，然后发到后端执行，结果再存到特定表里，前端做成报表，给客户大佬看……
实际上就是个 xxx sql analysis……

grqphql 也有占位符和参数…

人家跑局域网的

领导:又不是不能用

我以前也想过这问题，为什么前端写 SQL ？因为代码改起来方便，开发速度快啊。
当初的设想是，开发阶段前端写明文 SQL，发布阶段把 SQL 全部都用 hash 替代，然后后端校验 hash 有效性，再根据前端的 HASH，来还原明文 SQL 语句，并阻止未授权的 SQL 运行。
这样既保证了开发效率，又保证了安全性。

http，直接明文传输各种数据，都见怪不怪了。

graphql 吧，那个跟这不是一回事呀

对对对，就是前端求着后端自己来写 sql 的

hash 之后还咋还原？？

不需要还原，后端的 hash 白名单而已。开发明文阶段，后端每条语句都有缓存明文和对应 hash 值的。
生产环境只是简单查个表。

这不是我上家吗 哈哈

看使用范围, 如果是内部应用, 所有人拥有所有表操作权限, 或者就是个面馆管理系统, 恰好老板会点 sql, 也不是不行
要是还需要控制权限呢, 就考虑查之前做一下鉴权
要是还需要审计呢, 就考虑一下再加上 log
要是还需要公开使用呢...考虑一下再加上敏感字段加密, sql 防注入...不过公网公开的这种接口, 我还没遇到也就是了

用名单管理 sql，我敢保证想出这点子的人不是干活——包括但不限于编码、测试、评审——的。玩呢，这干活时间那不是翻倍，是翻几番。

为啥还有公司前端使用 SQL 拼接参数？简单来说，懒。深入一点可能是：甲方，或者更可能是乙方老板，压根就没打算做能用的东西。

一句话，又不是不能用

你说的应该是 graphql 这个吧

都是拿钱做事，安全这东西，得负责人懂程序，不然大家都是玩玩。。。