很多老板第一次认真看待安全，是在网站被挂马、后台被人登录、用户数据被打包下载之后。这时候再去查日志、补漏洞，成本往往比一开始做好防护高得多。
说实话，网站开发中常见的安全漏洞，绝大多数都不是什么高深技术，而是基础工作没做到位。下面按实战中最常踩的坑，一个个说清楚。
一、注入类漏洞：SQL 注入和命令注入
SQL 注入是最经典的漏洞。成因很简单：程序把用户输入直接拼进 SQL 语句。比如登录框里输入一段构造好的字符，就能绕过密码校验，甚至把整张用户表拖走。
常见做法与避坑：
- 用参数化查询或 ORM，不要手写字符串拼接
- 数据库账号按最小权限分配，只读业务就别给写权限
- 关闭生产环境的详细报错，报错信息本身就是情报
- 对输入做类型校验，比如 ID 只允许数字
命令注入同理。有些脚本开发场景需要调用系统命令处理图片、生成文件，如果把文件名直接拼进命令，攻击者就能顺带执行别的指令。这类问题在后台管理系统里尤其常见。
二、权限与越权：登录了不等于有权限
这是企业网站和后台系统里最容易被低估的一类。用户确实登录了，但访问了不该访问的数据。
分两种：
- 水平越权：普通用户 A 通过改 URL 里的订单号，看到了用户 B 的订单
- 垂直越权：普通用户直接访问管理员接口，比如删除用户、导出数据
一个具体场景：某预约类小程序开发项目，接口是 `/api/order/detail?id=1001`。前端只显示自己的订单，但后端没有校验这个订单属不属于当前用户。只要把 id 改成 1002，就能看到别人的手机号和地址。
做法：
- 每个涉及数据的接口，都要在服务端校验「当前用户是否有权访问这条数据」
- 不要依赖前端隐藏按钮来做权限控制
- 管理后台和用户端接口分开，鉴权逻辑独立
三、文件上传与文件包含
文件上传本身没问题，问题在于「上传之后能不能被执行」。
常见坑：
- 只校验前端后缀名，抓包改一下就能传 PHP、JSP
- 上传目录有执行权限，传个脚本直接拿到服务器
- 文件名可预测，攻击者能遍历下载
建议做法：
- 服务端校验文件类型，白名单而不是黑名单
- 上传目录禁止脚本执行，只允许静态访问
- 文件重命名，用随机串，不保留原始路径
- 图片类文件做二次处理，顺带去掉可能夹带的恶意内容
四、接口与业务逻辑漏洞
很多漏洞不在代码层面，而在业务流程里。比如：
- 短信验证码没有次数限制，可以被暴力枚举
- 支付回调没有验签，可以伪造「已支付」
- 优惠券可以并发领取，一人领一百张
- 密码找回流程可被绕过，直接重置他人密码
这类问题在 App开发 和小程序开发 里特别值得注意，因为接口暴露面比传统网站更广，很多人以为「App 里看不到接口就安全」，其实抓包工具一开，请求清清楚楚。
避坑建议：
- 关键接口加频率限制和风控
- 支付、退款等敏感操作必须服务端验签、二次确认
- 业务状态流转要在服务端判断，不能信前端传过来的状态
五、依赖组件与配置问题
不少企业网站出问题，不是自己写的代码有洞，而是用的开源框架、插件版本太旧。
- 第三方 CMS、建站系统长期不更新
- 中间件默认配置没改，比如后台弱口令、默认端口对外开放
- 云服务器安全组开得太大，数据库直接暴露公网
- 测试环境、备份文件、.git 目录被同步到线上
做法很朴素：定期更新依赖，上线前做一次配置检查，把不该对外开放的端口关掉，删掉线上多余的调试文件。
什么情况适合找 MIC Studio
如果你的项目属于下面几种情况，自己团队又没精力系统排查，找专业团队做一轮安全测试会更划算：
- 企业网站刚改版上线，涉及会员、表单、支付
- 小程序开发或 App开发 进入提测阶段，接口多、逻辑复杂
- 后台管理系统涉及多角色权限，越权风险高
- 需要做逆向测试，评估接口被批量调用、数据被抓取的风险
- 已经出过安全事件，需要定位原因并做加固
MIC Studio 的做法是先梳理资产和接口，再按注入、权限、上传、逻辑、配置几个方向做测试，输出可复现的问题清单和修复建议，而不是只给一份看不懂的扫描报告。
结尾：三条能马上做的事
1. 上线前做一次权限自查：把所有接口列出来，逐个问「不登录能不能访问」「换个用户 ID 能不能看到别人数据」。
2. 管好输入和输出：所有用户输入都校验，所有数据库操作都参数化，所有报错信息都不外泄。
3. 把安全当成持续动作：依赖定期更新，配置定期检查，重要版本上线前做一轮安全测试，别等出事再补。
安全不是一次性的项目，而是开发流程里的一部分。早一点想清楚，后面少很多麻烦。