去年冬天，全工一个电商网站的程师后台被人用一条SQL语句拖走了三百万条用户记录。事后复盘，全工漏洞出在一个看起来毫不起眼的程师搜索框——开发人员只在前端做了长度校验，后端直接拿参数拼了查询。全工这种事每天都在发生。程师Web安全工程师的全工工作，就是程师赶在攻击者之前，把这种口子堵上。全工

很多人以为这行就是程师拿着扫描器跑一遍，出份报告完事。全工真干起来完全不是程师那么回事。扫描器能发现的全工，通常是程师已知的、模式化的全工漏洞，比如过时的组件版本、缺失的响应头。但真正造成大规模数据泄露的，往往是业务逻辑层面的问题。举个例子，某平台的优惠券接口，正常用户只能领一张，但把请求里的user_id改成别人的，就能重复领取。扫描器不会告诉你这个，它不懂你的业务规则。你得自己坐在那儿，把整个领取流程走一遍，想清楚每一步的信任边界在哪里。

我习惯把Web安全拆成三层来看。最底层是代码和配置，SQL注入、XSS、CSRF、文件上传绕过，这些属于基本功。往上走是架构和协议，比如JWT令牌的签名校验、OAuth的回调地址白名单、CORS的配置粒度。再往上就是人的层面——运维有没有把测试环境暴露在公网，客服会不会被社会工程学套走验证码。三层里，越往上越难防，因为变量越多。

说个具体的。有次帮一个金融客户做渗透测试，前端登录接口做了图形验证码，输错三次锁定账户。看起来挺严。但我抓包发现，验证码的校验逻辑是在前端JS里做的，后端只检查了用户名和密码。我把请求里的验证码字段整个删掉，照样能登录。这就属于典型的“信任了不该信任的客户端”。修复方案也简单，把校验挪到服务端，但发现这个问题靠的是手动测试加一点直觉，工具帮不上忙。

做这行时间长了，会养成一种条件反射。看到任何用户输入的地方，脑子里自动开始过一遍：这个参数会进数据库吗？会回显到页面上吗？会拼进系统命令吗？会作为文件路径吗？四个问题问完，基本能判断出攻击面在哪。这种思维习惯比会用什么工具重要得多。工具会过时，Burp Suite的某个插件可能明年就没人维护了，但“永远不要信任客户端提交的任何数据”这条原则，十年没变过。

另一件常被忽略的事是沟通。你发现了一个高危漏洞，兴冲冲写进报告，开发团队回一句“这个接口在内网，不对外”。你得能说清楚，内网不代表安全，攻击者一旦通过钓鱼或者VPN漏洞进入内网，这个接口就是横向移动的跳板。还得给出具体的修复建议，不能只说“过滤特殊字符”，得告诉他是用参数化查询还是白名单校验，改哪一行代码。安全工程师的价值，一半在发现，一半在推动修复。

薪资方面，初级岗大概在15到25K之间，能独立做渗透测试和代码审计的中级工程师可以到30K以上。但别冲着钱来。这行需要持续学习，今天刚搞明白Log4j2的JNDI注入，明天又冒出个Spring4Shell。漏洞库每天都在更新，你停两周，可能就跟不上节奏了。真正留下来的，都是那种看到新漏洞公告会兴奋的人。

最后说个观察。很多公司招Web安全工程师，面试时问一堆OWASP Top 10的定义，却没人问“如果你发现业务部门为了赶进度，坚持要上线一个有已知漏洞的功能，你怎么办”。这个问题比任何技术题都难回答。安全是成本中心，业务是利润中心，两者天然有张力。能在这中间找到平衡点的人，才是真正成熟的Web安全工程师。