内容摘要：```html Web应用安全的核心问题在于 Web应用安全的核心问题在于 2017年，Equifax泄露了1.47亿人的数据。事后复盘，攻击者利用的漏洞是Apache Struts的一个

```html

Web应用安全的核心问题在于

2017年，Equifax泄露了1.47亿人的核心数据。事后复盘，问题攻击者利用的应用安于漏洞是Apache Struts的一个已知远程代码执行漏洞。这个漏洞在泄露事件发生的核心几个月前就发布了补丁。Equifax的问题安全团队确实收到了通知，也确实安排了修补——但有一个内部系统被漏掉了。应用安于就一个。核心然后整个防线崩塌。问题这跟技术多先进没太大关系。应用安于核心问题在于：所有安全机制最终都依赖人去正确执行，核心而人会出错、问题会偷懒、应用安于会遗忘。核心

我们总以为安全是问题技术对抗——加密算法够不够强，防火墙规则够不够严，WAF能不能拦住注入。这些当然重要。但去看看真实世界里那些被攻破的系统，绝大多数问题出在更基础的环节：一个没打补丁的服务器，一个被硬编码在代码里的数据库密码，一个离职员工没被注销的VPN账号。技术工具能做的，是把安全门槛抬高，让攻击成本变大。但它没法替你决定“这个补丁今天必须打”，也没法替你检查“那个离职流程有没有走完”。

我见过一个创业团队，产品做得挺漂亮，后端接口的权限校验却全靠前端路由控制。攻击者直接调API，就能拿到其他用户的数据。他们的开发工程师不是不懂安全，是赶进度的时候觉得“先这样，回头再补”。回头？回头往往就是永远不回。这种“先上线再说”的心态，比任何0day漏洞都致命。安全从来不是某个功能，它是贯穿整个开发流程的约束条件。但约束条件在业务压力面前，总是第一个被牺牲。

还有一个更隐蔽的问题：安全责任的稀释。开发觉得运维该管，运维觉得安全团队该管，安全团队觉得业务部门该负责。最后谁都没管。很多公司招了安全工程师，就以为安全有了着落。可一个安全工程师能盯几个项目？能审几行代码？真正要落地安全，得让写代码的人自己把安全当回事。但这又回到人的问题——你没法强迫一个人对他不理解的威胁保持警惕。

再说个细节。很多Web应用的安全漏洞，比如XSS或SQL注入，教科书上讲了二十年。防御方法早就成熟了：参数化查询、输出编码、内容安全策略。但你去扫一下现在互联网上的站点，这些老漏洞依然一抓一大把。为什么？因为每一代新入行的开发者都要重新学一遍，而老手可能因为换框架、换语言，把旧习惯带进新环境。安全知识没有形成肌肉记忆，它像是一本放在书架上的手册，需要的时候翻一下，不需要就忘了。

所以你看，核心问题不在于攻击技术有多高明，而在于防守方的组织能力、流程纪律和人的意识。攻击者只需要找到一个薄弱点，防守方却要守住所有点。这种不对称，注定了安全是一场持续消耗战。技术能帮你自动化一部分检查，能帮你快速响应，但它没法替你建立一种“安全是每个人的事”的文化。没有这种文化，再贵的设备也是摆设。

我并不是说技术没用。恰恰相反，好的技术能减少对人性的依赖。比如把安全扫描集成到CI/CD流水线里，代码合并前自动跑一遍，有问题就卡住。这比发邮件提醒“记得检查安全”有效得多。但设计这套流程的人，依然要理解业务、理解开发者的习惯、理解攻击者的思路。说到底，Web应用安全的核心问题，是如何让正确的事情变得容易做，让错误的事情变得难做。这既是个技术问题，更是个管理问题、心理问题。只盯着代码看，永远看不全。

Equifax那个被漏掉的系统，后来查出来是因为一个负责资产管理的员工休假了，交接没做到位。你看，多普通的一件事。安全溃败往往不是因为敌人太强，而是因为自己人太累、太忙、太相信“应该没问题”。

```