丁茂华1. Web安全防御的整体视角：纵深防御战略
1.1 现代Web安全的层次化防御理念
Web安全本质上是一场攻防不对称的战争。攻击者只需找到一个漏洞即可实现入侵，而防御者需要保护整个系统。这种不对称性使得纵深防御（Defense in Depth）成为现代Web安全的核心理念。
在实际项目中，我通常会构建三个核心防御层面：
-
渲染层安全：主要防护XSS、CSRF等客户端攻击。例如，某电商项目曾因未正确处理用户评论中的脚本标签，导致存储型XSS漏洞，攻击者能窃取其他用户的登录凭证。
-
应用层安全：防护SQL注入、命令注入等服务端漏洞。曾遇到一个案例，某CMS系统因直接拼接SQL语句，导致攻击者通过搜索框获取了数据库管理员权限。
-
数据层安全：保护敏感数据的存储和传输。去年审计的一个金融APP，就因为未加密存储用户身份证号，在数据库泄露事件中造成重大损失。
1.2 安全边界的重新定义
随着前后端分离架构的普及，安全边界已经从传统的服务器防护扩展到全链路防护。我在设计系统时，通常会绘制如下攻击面图：
code复制客户端安全 → 传输安全 → 服务端安全 → 数据存储安全
每个环节都需要特定的防护策略。例如，在最近的一个API项目中，我们不仅实现了服务端的JWT验证，还在客户端集成了CSP策略，并通过TLS双向认证强化了传输层安全。
关键经验：安全防护必须考虑各层之间的协同。比如设置HttpOnly的Cookie能防止XSS窃取，但需要配合SameSite属性才能有效防御CSRF。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. XSS防护：从输入到输出的全流程控制
2.1 XSS攻击的本质与变种
XSS的核心问题是用户输入被错误地执行为代码。根据多年实战经验，我将XSS分为三类典型场景：
-
反射型XSS：常见于错误消息页面。例如，某旅游网站搜索页面的错误提示
<script>alert(1)</script>直接输出未过滤的搜索关键词。 -
存储型XSS：论坛评论区是重灾区。曾见一个案例，攻击者在个人简介中植入恶意脚本，每个查看其资料的会员都会中招。
-
DOM型XSS：纯前端漏洞。某SPA应用因使用
eval(location.hash)导致攻击者能通过URL注入任意JS代码。
2.2 多层次XSS防护策略
输入验证与过滤
输入过滤是第一道防线，但不应过度依赖。我常用的Java过滤方案：
java复制public class XssFilter {
private static final Whitelist WHITELIST = Whitelist.basic()
.addTags("br","hr") // 允许的HTML标签
.addAttributes("a", "href"); // 允许的属性
public static String clean(String input) {
return Jsoup.clean(input, WHITELIST);
}
}
踩坑提醒：过度过滤会影响用户体验。曾有个项目过滤了所有特殊字符，导致用户无法正常输入包含&符号的产品编号。
输出编码
输出编码更为可靠。在Thymeleaf模板中：
html复制<!-- 安全输出 -->
<div th:text="${userContent}"></div>
<!-- 危险示例 -->
<div th:utext="${userContent}"></div>
对于纯前端渲染，建议使用textContent替代innerHTML：
javascript复制// 安全
element.textContent = userInput;
// 危险
element.innerHTML = userInput;
CSP策略配置
这是我常用的生产环境CSP配置：
code复制Content-Security-Policy:
default-src 'self';
script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https://*.example.com;
connect-src 'self' https://api.example.com;
frame-ancestors 'none';
3. CSRF防护：确保请求的合法性验证
3.1 CSRF攻击原理与危害
典型攻击案例：某银行转