去年一家做跨境电商的统安客户找过来，说后台被人拖了库，统安三十多万条订单信息挂在网上卖。统安排查日志发现，统安攻击入口是统安一个两年前上线的促销活动页面——开发图省事，直接把用户输入的统安优惠码拼进了SQL语句。这个页面早就不用了，统安代码还在服务器上跑着。统安web安全最操蛋的统安地方就在这：你防住了今天所有已知的洞，但半年前某个实习生随手写的统安一行代码，可能正等着被人翻出来。统安

SQL注入算是统安老生常谈，但直到今天它仍然是统安杀伤力最大的漏洞类型之一。原因不复杂——很多团队用ORM框架之后就觉得万事大吉，统安可一旦有人写原生查询、统安拼接排序字段或者动态表名，防线就破了。我见过一个系统，登录接口用了参数化查询，但"忘记密码"那个接口图方便直接字符串拼接邮箱地址，结果一样被注。安全不是看你最强的地方有多强，是看你最弱的那个口子有多弱。

XSS的问题更隐蔽。反射型XSS好歹还能靠WAF拦一部分，存储型XSS才要命。有个社交类产品，用户昵称没做转义就渲染到页面上，攻击者把昵称改成一段脚本，每个访问他主页的人都中招。更离谱的是，这段脚本还能自动发帖，一传十十传百，半天时间整个平台沦陷。防御手段说来说去就那几条：输出编码、CSP头、HttpOnly Cookie。但真正落地的团队有多少？我翻过不少生产环境的响应头，CSP配置率大概不到两成。

CSRF经常被忽略，因为它的利用条件看起来比较苛刻。但你想想，一个后台管理系统的"删除用户"接口如果只靠Cookie鉴权，没有CSRF Token，攻击者只需要在论坛帖子里嵌入一个自动提交的表单，管理员点开帖子的一瞬间，用户就被删了。SameSite Cookie属性现在浏览器支持已经很好了，设成Lax能挡掉大部分场景，但总有人设成None还不加Secure，等于门开着还把钥匙插在锁上。

文件上传漏洞是我个人觉得最容易被低估的。很多开发者的防御逻辑是"检查后缀名"，但攻击者传一个`.php.jpg`，如果你的服务器配置有问题，Apache可能仍然把它当PHP解析。还有人用黑名单过滤，禁止`php`后缀，结果攻击者传`.phtml`、`.php5`、`.phar`，照样执行。白名单才是正路，而且文件存储目录必须禁止脚本执行权限。我见过一个案例，攻击者上传了一个伪装成头像的webshell，在里面蹲了四个月，把数据库结构摸得一清二楚才动手。

说点实际的。安全这件事没有一劳永逸的方案，它更像是一个持续的对抗日程。SDL流程要跑起来，代码审计不能省，上线前的渗透测试别糊弄。但更关键的是心态——别觉得自己的系统小、没价值就不会被盯上。自动化扫描器每天在互联网上扫几十亿次，你的漏洞不需要被人"发现"，它自己会被找到。修一个洞的成本，永远比出事之后擦屁股低得多。