006_Web安全攻防实战：Web应用程序框架漏洞分析与防护策略

引言

随着Web应用程序的复杂性不断增加，开发者越来越依赖各种Web框架来提高开发效率和代码质量。这些框架提供了丰富的功能和组件，简化了常见任务的实现，但同时也引入了新的安全风险。根据2025年最新的Web安全报告，超过75%的Web应用安全漏洞与框架或其组件直接相关。

本文将系统地介绍常见Web应用程序框架的安全漏洞，分析其成因和危害，并提供详细的防护策略。通过深入理解这些框架漏洞，开发者和安全专业人员可以构建更加安全的Web应用程序。

第一章 Web框架安全概述

1.1 现代Web框架简介

Web框架是一种软件框架，旨在支持Web应用程序的开发，提供了预定义的组件和工具，使开发者能够更高效地构建Web应用。

主流Web框架分类

1. 服务端框架
   • Python: Django, Flask, FastAPI
   • Java: Spring Boot, Jakarta EE
   • JavaScript/Node.js: Express, Koa, NestJS
   • PHP: Laravel, Symfony, CodeIgniter
   • Ruby: Ruby on Rails
   • Go: Gin, Echo, Fiber
2. 前端框架
   • React, Vue.js, Angular
   • Svelte, Preact, Solid
3. 全栈框架
   • Next.js, Nuxt.js
   • Remix, SvelteKit
   • Meteor

Web框架的安全特性

现代Web框架通常包含以下安全特性：

• 内置的XSS防护机制
• CSRF保护
• 输入验证和过滤
• 安全的会话管理
• ORM提供的SQL注入防护
• 模板引擎安全设置

1.2 Web框架漏洞的特点

Web框架漏洞具有一些独特的特点，这些特点影响着漏洞的发现、利用和修复过程。

1. 广泛的影响范围

• 单一框架漏洞可能影响数以万计的应用
• 漏洞被公开后可能迅速被自动化工具利用
• 修复需要应用开发者更新框架版本

2. 漏洞类型多样性

• 框架核心漏洞：影响所有使用该框架的应用
• 组件漏洞：框架依赖的第三方库中的漏洞
• 配置相关漏洞：由于错误配置导致的安全问题
• 集成漏洞：框架与其他系统集成时出现的安全问题

3. 难以直接检测

• 框架漏洞通常隐藏在复杂的代码库中
• 应用可能通过自定义代码掩盖漏洞症状
• 不同版本的框架漏洞表现可能不同

4. 修复复杂性

• 框架升级可能导致应用兼容性问题
• 某些框架可能停止维护，使漏洞永久存在
• 修复可能需要同时更新多个依赖组件

1.3 2025年Web框架安全趋势

Web框架安全在2025年呈现以下趋势：

1. 零信任架构集成

• 框架原生支持零信任安全模型
• 细粒度的访问控制成为标准功能
• 持续验证用户和设备身份

2. 安全默认配置

• 框架默认启用更严格的安全设置
• 不安全的配置选项需要显式启用
• 自动检测和警告不安全的配置

3. 内置安全扫描

• 开发阶段自动检测潜在安全问题
• 集成到CI/CD流程的安全检查
• 实时监控和警报机制

4. 人工智能辅助安全

• AI驱动的漏洞检测和修复建议
• 智能代码分析识别潜在安全风险
• 自适应防护机制应对新型威胁

第二章 常见Web框架漏洞分析

2.1 Python框架安全漏洞

Python框架如Django和Flask是最受欢迎的Web框架之一，它们的安全漏洞值得特别关注。

1. Django安全漏洞

• SQL注入漏洞：
  • 虽然Django ORM提供了基本保护，但复杂查询仍可能存在风险
  • 示例：User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'")
  • 修复：使用参数化查询 User.objects.raw("SELECT * FROM auth_user WHERE username = %s", [username])
• CSRF保护绕过：
  • Django使用CSRF令牌防止跨站请求伪造，但某些配置可能导致保护失效
  • 常见问题：错误配置CSRF_COOKIE_SECURE或CSRF_TRUSTED_ORIGINS
  • 风险：允许未授权的跨站请求
• 缓存中毒漏洞：
  • Django缓存系统在特定条件下可能受到缓存投毒攻击
  • 影响：向应用提供错误或恶意内容
  • 修复：正确配置缓存键和缓存控制头
• 序列化漏洞：
  • 使用不安全的序列化方法可能导致远程代码执行
  • 风险：pickle模块的不安全使用
  • 修复：使用JSON序列化或其他安全的序列化方法
• CVE案例分析：
  • CVE-2023-43665：Django 4.2.5版本之前的SQL注入漏洞
  • CVE-2022-41942：Django 4.1.3版本之前的URL路径验证绕过

2. Flask安全漏洞

• 不安全的会话管理：
  • 默认使用签名Cookie存储会话，可能存在会话固定和劫持风险
  • 风险：如果SECRET_KEY未正确设置或泄露
  • 修复：使用复杂的SECRET_KEY并定期轮换
• 缺少XSS防护：
  • Flask不自动转义模板变量，需要显式使用|safe过滤器
  • 风险：不当使用可能导致XSS漏洞
  • 修复：默认对所有输出进行HTML转义
• 不安全的重定向：
  • 未验证的重定向参数可能导致开放式重定向
  • 示例：@app.route('/redirect') def redirect_to(): return redirect(request.args.get('url'))
  • 修复：验证重定向URL在白名单中
• 命令注入风险：
  • 使用subprocess模块时的命令注入风险
  • 风险：未过滤的用户输入传递给系统命令
  • 修复：使用参数列表而不是字符串命令
• CVE案例分析：
  • CVE-2023-30897：Flask 2.3.2版本之前的会话Cookie签名绕过
  • CVE-2022-3602：Flask依赖的Python cryptography库漏洞

3. FastAPI安全漏洞

• 依赖注入安全问题：
  • 不当的依赖注入可能导致权限绕过
  • 风险：依赖项中的安全检查可能被绕过
  • 修复：在所有路由中正确应用安全依赖
• Pydantic模型验证绕过：
  • 某些情况下可以绕过Pydantic的数据验证
  • 风险：接收不符合预期的数据格式
  • 修复：使用严格的模型定义和验证器
• OpenAPI文档信息泄露：
  • 自动生成的API文档可能泄露敏感信息
  • 风险：暴露内部系统结构和端点
  • 修复：限制文档访问或移除敏感端点
• CORS配置错误：
  • 过于宽松的CORS配置可能导致安全问题
  • 风险：allow_origins=['*']可能允许任意域名访问
  • 修复：指定明确的允许来源列表

2.2 Java框架安全漏洞

Java框架，特别是Spring系列，在企业应用中广泛使用，其安全漏洞影响重大。

1. Spring Framework漏洞

• Spring4Shell/CVE-2022-22965：
  • 远程代码执行漏洞，影响Spring Framework 5.3.x和5.2.x
  • 成因：数据绑定机制中的漏洞
  • 影响：允许攻击者在目标系统上执行任意代码
  • 修复：升级到Spring Framework 5.3.18+或5.2.20+
• Spring Cloud Function SpEL注入/CVE-2022-22963：
  • 表达式语言注入漏洞
  • 成因：SpEL表达式处理不当
  • 影响：远程代码执行
  • 修复：升级到Spring Cloud Function 3.1.7+或3.2.3+
• Spring Security认证绕过：
  • 某些配置可能导致认证检查被绕过
  • 风险：未授权用户访问受保护资源
  • 修复：正确配置安全过滤器链
• Spring Data MongoDB注入：
  • MongoDB查询构造不当可能导致注入漏洞
  • 风险：未授权数据访问或篡改
  • 修复：使用安全的查询方法和参数绑定
• CVE案例分析：
  • CVE-2023-20860：Spring Security中的CSRF令牌验证绕过
  • CVE-2021-22060：Spring Cloud Gateway中的代码注入漏洞

2. Jakarta EE/EJB漏洞

• EJB远程调用漏洞：
  • 不安全的远程接口可能被滥用
  • 风险：未授权访问或操作
  • 修复：实施适当的身份验证和授权
• JNDI注入/CVE-2021-44228（Log4Shell）：
  • 虽然主要影响Log4j，但在Java EE应用中广泛存在
  • 成因：JNDI查找功能处理不当
  • 影响：远程代码执行
  • 修复：更新相关组件，禁用危险功能
• 注入漏洞：
  • JPA/Hibernate查询构造不当可能导致注入
  • 风险：SQL注入、JPQL注入
  • 修复：使用参数化查询
• 不安全的反序列化：
  • Java反序列化漏洞，如Apache Commons Collections
  • 影响：远程代码执行
  • 修复：使用安全的序列化库，限制反序列化类

3. Java MVC框架漏洞

• Struts2漏洞：
  • CVE-2017-5638（Struts2 S2-045）：远程代码执行
  • CVE-2018-11776（Struts2 S2-057）：路径遍历
  • 成因：参数处理和表达式解析中的安全缺陷
  • 修复：升级到最新版本，应用安全补丁
• JSF漏洞：
  • 视图状态处理不当导致的漏洞
  • 风险：信息泄露、代码执行
  • 修复：启用状态加密，正确配置CSRF保护

2.3 JavaScript/Node.js框架漏洞

Node.js和相关框架在现代Web开发中扮演着重要角色，但其安全漏洞也日益增多。

1. Express.js漏洞

• 路径遍历漏洞：
  • 静态文件服务配置不当可能导致路径遍历
  • 示例：app.use(express.static(__dirname + '/public'))
  • 风险：/../../../etc/passwd可能访问系统文件
  • 修复：使用path.join()和绝对路径
• 中间件配置错误：
  • 不当的中间件顺序可能绕过安全检查
  • 风险：安全控制被绕过
  • 修复：确保安全中间件在路由处理前执行
• 模板注入：
  • 使用EJS、Pug等模板引擎时的注入风险
  • 风险：代码执行、信息泄露
  • 修复：避免使用不安全的模板语法
• CVE案例分析：
  • CVE-2022-24999：Express.js依赖的qs库中的原型污染
  • CVE-2021-23337：Express.js中的XSS漏洞

2. React/Vue.js/Angular前端框架漏洞

• React安全问题：
  • dangerouslySetInnerHTML属性导致的XSS风险
  • 示例：<div dangerouslySetInnerHTML={{__html: userInput}} />
  • 风险：用户输入未经过滤直接渲染
  • 修复：避免使用dangerouslySetInnerHTML，使用React的自动转义
• Vue.js安全问题：
  • v-html指令导致的XSS风险
  • 模板表达式注入
  • 风险：客户端代码执行
  • 修复：避免使用v-html处理不可信内容，使用Vue的内置转义
• Angular安全问题：
  • 模板注入漏洞
  • 信任不安全的内容
  • 风险：客户端代码执行
  • 修复：使用Angular的DomSanitizer，避免eval()和Function构造函数
• 客户端路由安全：
  • 前端路由保护不能替代后端认证
  • 风险：敏感页面可能通过绕过前端路由访问
  • 修复：始终在服务器端实施访问控制

3. NestJS/Next.js全栈框架漏洞

• NestJS安全问题：
  • 装饰器使用不当导致的安全问题
  • 守卫配置错误导致的授权绕过
  • 风险：权限控制失效
  • 修复：正确配置守卫、拦截器和过滤器
• Next.js安全问题：
  • API路由缺少输入验证
  • 服务器端渲染中的信息泄露
  • 风险：数据泄露、注入攻击
  • 修复：对所有API端点实施验证，避免在前端暴露敏感信息
• 服务器端状态管理安全：
  • 不当的状态管理可能导致信息泄露
  • 风险：用户可以访问其他用户的数据
  • 修复：确保状态隔离和正确的用户上下文管理

2.4 PHP框架安全漏洞

PHP框架仍然是Web开发中使用最广泛的框架之一，了解其安全漏洞至关重要。

1. Laravel安全漏洞

• 反序列化漏洞：
  • CVE-2018-15133：Laravel 5.6.38之前版本的反序列化漏洞
  • 成因：unserialize()函数处理不当
  • 影响：远程代码执行
  • 修复：使用安全的序列化方法
• CSRF保护绕过：
  • 某些配置可能导致CSRF保护失效
  • 风险：跨站请求伪造攻击成功
  • 修复：确保所有状态更改请求都验证CSRF令牌
• 配置信息泄露：
  • 环境文件(.env)可能被意外暴露
  • 风险：数据库凭据和其他敏感信息泄露
  • 修复：确保.env文件在Web根目录之外，配置Web服务器禁止访问
• ORM查询注入： 不当的查询构建可能导致SQL注入示例：User::whereRaw("username = '{
• CVE案例分析：
  • CVE-2023-35887：Laravel 10.10.1之前版本的输入验证绕过
  • CVE-2021-3129：Laravel 8.40.0之前版本的命令注入漏洞

2. Symfony安全漏洞

• 组件注入漏洞：
  • 依赖注入容器配置不当可能导致组件注入
  • 风险：服务容器被滥用
  • 修复：正确配置服务容器和依赖注入
• 会话固定漏洞：
  • 会话管理中的安全缺陷
  • 风险：会话被劫持
  • 修复：实施会话轮换和验证
• 模板注入漏洞：
  • Twig模板引擎的沙箱绕过
  • 风险：代码执行、信息泄露
  • 修复：使用最新版本的Twig，配置适当的沙箱策略
• CVE案例分析：
  • CVE-2022-24894：Symfony 5.4.7之前版本的CSRF令牌绕过
  • CVE-2021-21424：Symfony HTTP缓存组件中的缓存中毒

第三章 Web框架组件安全

3.1 ORM和数据库交互安全

对象关系映射(ORM)工具简化了数据库操作，但不当使用可能导致各种安全问题。

1. ORM中的SQL注入风险

常见问题：

• 使用原始SQL查询时的注入风险
• 不安全的查询构建器用法
• 不当的参数绑定

各框架示例：

Django：

# 不安全：
User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'")
# 安全：
User.objects.raw("SELECT * FROM auth_user WHERE username = %s", [username])

Laravel：

// 不安全：
User::whereRaw("username = '{$username}'")->get();
// 安全：
User::where('username', $username)->get();

Hibernate：

// 不安全：
String query = "FROM User WHERE username = '" + username + "'";
// 安全：
Query query = session.createQuery("FROM User WHERE username = :username");
query.setParameter("username", username);

防护策略：

• 始终使用参数化查询
• 避免使用原始SQL，优先使用ORM的查询构建器
• 实施最小权限原则，限制数据库用户权限
• 对用户输入进行严格验证和过滤

2. NoSQL注入风险

常见问题：

• MongoDB查询操作符注入
• Redis命令注入
• CouchDB查询注入

MongoDB注入示例：

// 不安全：直接使用用户输入构建查询
db.users.find({ username: username, password: password });

// 如果用户输入 password = { $ne: null }，可能绕过认证

防护策略：

• 验证输入类型和格式
• 使用查询构建器而不是原始查询
• 实施输入白名单机制
• 限制NoSQL数据库的操作权限

3. 数据库连接池和凭据管理

常见问题：

• 硬编码的数据库凭据
• 连接池配置不安全
• 数据库连接未正确关闭

安全配置建议：

• 使用环境变量或安全的配置管理系统存储凭据
• 配置适当的连接池大小和超时
• 实施连接加密（如TLS/SSL）
• 限制数据库连接的网络访问

各框架配置示例：

Spring Boot：

# application.properties
spring.datasource.url=jdbc:mysql://localhost:3306/mydb?useSSL=true&requireSSL=true
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}
spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.idle-timeout=30000

Django：

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': os.environ.get('DB_NAME'),
        'USER': os.environ.get('DB_USER'),
        'PASSWORD': os.environ.get('DB_PASSWORD'),
        'HOST': os.environ.get('DB_HOST'),
        'PORT': os.environ.get('DB_PORT'),
        'OPTIONS': {
            'sslmode': 'require',
        },
    }
}

3.2 模板引擎安全

模板引擎简化了Web页面生成，但不当使用可能导致各种安全问题。

1. 模板注入漏洞

常见问题：

• 模板中的动态内容未经过滤
• 使用不安全的模板语法
• 模板沙箱绕过

各框架示例：

Jinja2 (Flask)：

# 不安全：
template = f"<h1>Hello {username}</h1>"
rendered = render_template_string(template)

# 如果username包含恶意代码，可能导致XSS或服务器端模板注入

Twig (Symfony)：

{# 不安全：允许执行表达式 #}
{{ userInput }}

{# 当userInput包含 {{ 1+1 }} 等表达式时可能被执行 #}

服务器端模板注入(Server-Side Template Injection)：

• 风险：远程代码执行、信息泄露
• 示例：当模板引擎允许执行代码表达式时
• 修复：使用沙箱模式，限制模板中的表达式功能

2. XSS防护在模板中的应用

自动转义机制：

• 大多数现代模板引擎默认启用HTML转义
• 了解各框架的转义规则和例外情况
• 避免禁用自动转义功能

安全输出示例：

Django模板：

<!-- 自动转义（默认） -->
{{ user_input }}

<!-- 显式禁用转义（谨慎使用） -->
{{ user_input|safe }}

ERB (Ruby on Rails)：

<!-- 自动转义 -->
<%= user_input %>

<!-- 显式禁用转义 -->
<%== user_input %>

自定义过滤器和辅助函数：

• 为特定内容类型创建安全的输出过滤器
• 实施内容安全策略(CSP)作为额外防护层
• 使用白名单方法过滤允许的HTML标签和属性

3. 模板缓存安全

常见问题：

• 缓存敏感信息
• 缓存中毒
• 缓存投毒

安全建议：

• 避免缓存包含用户特定信息的页面
• 正确配置缓存键，包含用户上下文
• 实施缓存验证机制
• 设置适当的缓存过期策略

缓存控制示例：

// Laravel缓存控制
Cache::put('user_data_'.auth()->id(), $userData, 60); // 包含用户ID在缓存键中

// Django缓存控制
cache.set(f'user_data_{request.user.id}', user_data, 60) // 包含用户ID在缓存键中

3.3 认证与授权组件安全

认证和授权是Web应用安全的核心组件，框架提供的认证机制需要正确配置才能有效防护。

1. 认证机制安全

密码存储安全：

• 使用强哈希算法（bcrypt、Argon2）
• 实施适当的盐值策略
• 定期更新哈希算法和参数

各框架密码处理：

Django：

# 自动使用bcrypt/Argon2
user = User.objects.create_user('username', 'email@example.com', 'password')

Laravel：

// 自动使用bcrypt
$user->password = Hash::make('password');

Spring Security：

// 使用BCryptPasswordEncoder
@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(12);
}

会话管理安全：

• 生成安全的会话标识符
• 实施会话超时
• 防止会话固定攻击
• 在认证成功后轮换会话ID

会话安全配置：

Express.js：

app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: {
    httpOnly: true,
    secure: true,  // 仅HTTPS
    sameSite: 'strict',
    maxAge: 3600000 // 1小时
  },
  resave: false,
  saveUninitialized: false
}));

Django：

# settings.py
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = 'Strict'
SESSION_EXPIRE_AT_BROWSER_CLOSE = False
SESSION_COOKIE_AGE = 3600  # 1小时

2. 授权机制安全

权限控制模型：

• 基于角色的访问控制(RBAC)
• 基于属性的访问控制(ABAC)
• 细粒度权限控制

各框架授权实现：

Spring Security：

// 方法级权限控制
@PreAuthorize("hasRole('ADMIN') or @securityService.isOwner(#id)")
public User getUserById(Long id) {
    // ...
}

Laravel：

// 中间件权限控制
Route::get('/admin', function () {
    // 管理员操作
})->middleware('can:admin');

Django：

# 视图权限控制
@permission_required('auth.view_user')
def user_list(request):
    # ...

权限检查绕过防护：

• 实施多层权限检查
• 在数据访问层也进行权限验证
• 避免仅依赖前端权限控制
• 记录和监控权限相关的异常

3. 多因素认证安全

框架集成：

• 了解各框架对MFA的支持情况
• 使用经过验证的MFA库和服务
• 正确实现和配置MFA工作流

安全实践：

• 使用基于时间的一次性密码(TOTP)
• 支持备用认证方式
• 妥善处理设备记住功能
• 限制MFA尝试次数

示例实现：

Django + django-otp：

from django_otp.plugins.otp_totp.models import TOTP

def setup_2fa(user):
    totp = TOTP.objects.create(user=user)
    totp.save()
    return totp.config_url  # 返回用于QR码的URL

Node.js + speakeasy：

const speakeasy = require('speakeasy');

function generateSecret() {
    return speakeasy.generateSecret({
        name: 'MyApp:' + user.email
    });
}

function verifyToken(secret, token) {
    return speakeasy.totp.verify({
        secret: secret,
        encoding: 'base32',
        token: token
    });
}

3.4 输入验证与输出编码组件

输入验证和输出编码是防止注入攻击的第一道防线，框架提供的相关组件需要正确使用。

1. 输入验证组件安全

验证机制：

• 服务器端验证（必须）
• 客户端验证（辅助）
• 多层验证策略

各框架验证实现：

FastAPI：

from pydantic import BaseModel, EmailStr, validator

class UserCreate(BaseModel):
    email: EmailStr
    password: str
    
    @validator('password')
    def validate_password(cls, v):
        if len(v) < 8:
            raise ValueError('密码长度至少为8个字符')
        return v

Laravel：

$request->validate([
    'email' => 'required|email',
    'password' => 'required|min:8|regex:/^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{8,}$/'
]);

Spring Boot：

import javax.validation.constraints.*;

public class UserDTO {
    @Email(message = "邮箱格式不正确")
    @NotBlank(message = "邮箱不能为空")
    private String email;
    
    @Size(min = 8, message = "密码长度至少为8个字符")
    private String password;
    
    // getters and setters
}

验证绕过防护：

• 验证所有用户输入，包括隐藏字段和HTTP头
• 实施白名单验证策略
• 验证数据类型和格式
• 验证业务逻辑约束

2. 输出编码组件安全

编码类型：

• HTML编码
• JavaScript编码
• URL编码
• CSS编码
• SQL编码

框架自动编码：

• 了解各框架的默认编码行为
• 避免禁用自动编码功能
• 为特殊情况使用正确的编码函数

手动编码示例：

Django：

from django.utils.html import escape, mark_safe
from django.utils.text import slugify
from django.utils.http import urlquote

safe_html = mark_safe(escape(user_input))
safe_url = urlquote(user_input)

Node.js：

const escapeHtml = require('escape-html');
const querystring = require('querystring');

const safeHtml = escapeHtml(userInput);
const safeUrl = querystring.escape(userInput);

PHP：

$safeHtml = htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');
$safeUrl = urlencode($userInput);
$safeJs = json_encode($userInput, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT);

上下文感知编码：

• 根据输出位置选择适当的编码方式
• 在HTML属性中使用引号和编码
• 在JavaScript上下文中使用JSON编码
• 在URL参数中使用URL编码

3. 内容安全策略(CSP)配置

CSP实现方式：

• HTTP响应头
• 元标签
• 框架集成

框架配置示例：

Express.js：

const helmet = require('helmet');

app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", 'trusted-cdn.com'],
    styleSrc: ["'self'", 'trusted-cdn.com', "'unsafe-inline'"],
    imgSrc: ["'self'", 'data:'],
    connectSrc: ["'self'"]
  }
}));

Django：

# settings.py
CSP_DEFAULT_SRC = ("'self'",)
CSP_SCRIPT_SRC = ("'self'", 'trusted-cdn.com')
CSP_STYLE_SRC = ("'self'", 'trusted-cdn.com', "'unsafe-inline'")
CSP_IMG_SRC = ("'self'", 'data:')

Spring Security：

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.headers()
            .contentSecurityPolicy("default-src 'self'; script-src 'self' trusted-cdn.com; style-src 'self' trusted-cdn.com 'unsafe-inline'; img-src 'self' data:")
            .and()
            .xssProtection().block(true)
            .and()
            .contentTypeOptions();
    }
}

CSP报告和监控：

• 配置CSP报告端点
• 监控和分析违反CSP的行为
• 逐步实施和严格化CSP策略
• 使用report-only模式进行测试