2023年，漏洞某大型电商平台的漏洞一次例行安全扫描中，工程师发现一个商品详情接口能通过修改URL中的漏洞数字ID，直接读取其他商家未上架的漏洞库存信息。问题出在权限校验只在前端做了，漏洞后端接口裸奔。漏洞这类漏洞在OWASP Top 10里排第一—— Broken Access Control，漏洞访问控制失效。漏洞

访问控制失效：最容易被忽略的漏洞“门没锁”

很多开发者觉得“用户看不到入口就安全”，但攻击者不看界面，漏洞直接调接口。漏洞一个普通用户改个参数就能变成管理员，漏洞或者看到别人的漏洞订单。我见过一个系统，漏洞删除操作的漏洞接口是 POST /api/delete?id=123，没有任何token校验。只要知道id，谁都能删。修复方式不复杂：每个请求都要在服务端验证当前用户是否有权操作目标资源。别信前端传过来的角色字段。

加密失败：数据裸奔的代价

某医疗App把用户身份证号用Base64编码后存进数据库，开发以为这是“加密”。Base64是编码，不是加密。真正的问题在于：敏感数据在传输和存储时没有用强加密。TLS配置错误、硬编码密钥、用MD5存密码——这些都算加密失败。密码应该用bcrypt或argon2，别再用SHA256加盐了，GPU撞库快得吓人。

注入攻击：SQL注入没死，只是换了马甲

预编译语句普及后，传统SQL注入少了。但NoSQL注入、LDAP注入、甚至XPath注入还在。一个真实案例：某API用MongoDB，查询条件是 { "username": req.body.username, "password": req.body.password}。攻击者提交 { "username": { "$ne": null}, "password": { "$ne": null}}，直接绕过登录。ORM不是万能药，拼接查询字符串的地方依然危险。

不安全设计：架构阶段的坑

这不是代码写错，是设计就没考虑安全。比如密码找回功能，验证码是4位数字，没次数限制。攻击者写个脚本跑一万次，总能撞对。再比如优惠券系统，允许同一用户无限次领取，只是前端按钮置灰。设计阶段就该做威胁建模：谁可能攻击？怎么攻击？成本多高？

安全配置错误：默认值害死人

云存储桶公开可读、数据库默认密码没改、错误堆栈直接返回给用户、开了不必要的端口。我见过一个生产环境，Elasticsearch的9200端口对公网开放，里面存着所有用户日志。配置错误不需要高超技术，一个Shodan搜索就能找到几万台这样的机器。

易受攻击和过时的组件

Log4j2漏洞爆发时，很多团队才发现自己依赖树里藏着它。你写的代码没问题，但引用的第三方库有已知CVE。建议用 npm audit、OWASP Dependency-Check 定期扫。别用不再维护的库，别为了省事锁死老版本。

身份认证和识别失败

允许用户用“123456”当密码、登录接口没有速率限制、会话ID暴露在URL里、登出后token依然有效。某社交平台曾允许攻击者通过枚举手机号+固定验证码“000000”登录任意账户。认证逻辑要经得起暴力破解和凭证填充攻击。

软件和数据完整性失败

从不可信源下载更新、没校验签名、CI/CD管道被投毒。SolarWinds事件就是典型：攻击者篡改了更新包，几千家客户中招。你的构建产物有没有校验哈希？更新包有没有签名验证？

安全日志和监控失败

被入侵了三个月才发现，因为没日志。或者有日志但没人看。关键操作要记录：登录、权限变更、数据导出。日志本身也要防篡改，别让攻击者删了。设置告警：半夜三点有人从陌生IP登录管理员账户，应该发短信。

服务端请求伪造（SSRF）

应用从用户提供的URL抓取图片，攻击者填 http://169.254.169.254/latest/meta-data/，拿到云服务器的临时凭证。SSRF在云原生环境里特别危险。修复：白名单限制域名、禁止访问内网IP、不要跟随重定向。

这十类漏洞没有哪一个是新发明。它们反复出现，因为开发速度永远快过安全评审。我的建议：把访问控制和注入检查做成自动化测试，每次提交都跑。加密和配置用基础设施即代码来管。别等渗透测试报告出来才修，那时候数据可能已经泄露了。