只要你的网站、小程序或 App 对外提供服务，就一定会被扫描、被试探、被攻击，区别只是有没有被发现而已。很多团队把精力全放在功能开发和上线速度上，安全测试一拖再拖，结果一个越权接口或者一个上传点，就能让整个系统失守。MIC Studio 在长期的安全测试与逆向测试服务中反复看到同一个规律：真正打穿系统的，往往不是多高深的技术，而是几类被忽视的老问题。这篇文章把网站安全测试里最常见的漏洞讲透，并给出可以直接照着做的加固建议。
一、先搞清楚安全测试的目标和边界
安全测试不是买一套扫描器跑一遍就交差。它要回答的是三个问题：攻击者能从哪个入口进来？进来之后能拿到多少东西？拿到之后能造成多大破坏？
按测试方式分，通常有三类：
- 黑盒测试：完全模拟外部攻击者，不掌握源码和账号，最接近真实攻击场景；
- 白盒测试：结合源码审计，能发现黑盒测不到的深层逻辑问题；
- 灰盒测试：拿到部分账号或接口文档，效率最高，适合迭代频繁的项目。
对大多数中小型项目来说，优先测接口层和权限层，性价比最高。因为这两块出问题最频繁，后果也最严重——数据泄露、越权操作、后台接管，基本都是从这里开始的。
二、SQL 注入：老问题，依然是头号杀手
SQL 注入存在了二十多年，但至今仍是各类漏洞榜单的常客。原因很简单：只要有一处 SQL 是拼接出来的，就可能被利用。
典型场景：
- 登录接口用字符串拼接查询用户，输入 `' or '1'='1` 直接绕过密码；
- 列表查询的排序字段、搜索条件直接拼进 SQL，导致报错注入或时间盲注；
- 部分老系统用 ORM 但拼接了原生 SQL，同样存在风险。
加固建议：
- 全面使用参数化查询（预编译语句），从代码规范层面禁止字符串拼接 SQL；
- 排序字段、表名这类无法参数化的位置，用白名单校验，只允许预设值；
- 数据库账号遵循最小权限原则，业务账号不给 DROP、FILE、GRANT 等高危权限；
- 生产环境关闭详细报错回显，避免泄露表结构和数据库版本；
- 引入 WAF 作为补充防线，但不要把它当成唯一防护。
三、XSS 跨站脚本：潜伏最久的注入
XSS 的本质是用户输入被当成代码执行。存储型 XSS 危害最大，因为它会长期躺在页面里，影响每一个访问者。
典型场景：
- 评论区、昵称、个人签名直接输出到页面；
- 富文本编辑器允许 `