第 5 卷

• 核心解决方案：

1. 主动刷新缓存：通过Service Worker主动删除旧缓存，或调用CDN的缓存刷新接口，删除CDN节

点上的旧缓存。

1. 短时效协商缓存：对无法哈希命名的资源（如index.html），设置Cache-Control: no-cache，

强制每次请求都验证资源，确保及时获取更新。

四、CDN缓存与浏览器缓存的协同

• 核心原则：CDN缓存作为“中间代理缓存”，应与浏览器缓存规则保持一致，同时承担“就近分

发”和“源站保护”的作用。

• 协同策略：

1. CDN节点缓存规则同步源站：CDN应遵循源站返回的Cache-Control规则（如max-age、

public/private），避免CDN缓存与浏览器缓存冲突。

1. CDN设置更长期的缓存：CDN节点的缓存过期时间可略长于浏览器（如浏览器max-

age=31536000秒，CDN设置为31622400秒），即使浏览器缓存过期，仍可从CDN快速获取资源。

1. 配置Vary: Accept-Encoding：CDN需缓存不同编码格式（gzip/brotli）的资源，避免向不同浏

览器返回错误编码的资源。

五、HTTP1.0与HTTP1.1缓存机制的差异

• HTTP1.0：仅支持Expires（绝对时间戳）和Pragma: no-cache，依赖客户端本地时间，易出现缓

存失效问题。

• HTTP1.1：新增Cache-Control（支持max-age、public/private等多指令）、ETag，优先级高于

Expires，解决了HTTP1.0缓存的缺陷，支持更精准的缓存控制。

• 兼容策略：服务器同时返回Cache-Control和Expires，确保HTTP1.0老浏览器也能正常使用缓存。

1. 什么是跨站脚本攻击（XSS）？如何防止XSS攻击？

跨站脚本攻击（Cross-Site Scripting，简称XSS）是一种常见的Web安全漏洞，攻击者通过在目标网站注入恶意JavaScript脚本（或HTML代码），当用户访问包含恶意脚本的页面时，脚本被浏览器执

行，从而实现窃取用户Cookie、劫持会话、伪造请求、传播恶意内容等攻击目的。XSS的核心危害是「利用用户的身份在目标网站上执行恶意操作」，因为注入的脚本会在用户的浏览器环境中运行，拥

有与用户相同的访问权限。

一、XSS攻击的三种主要类型

• 攻击流程：攻击者将恶意脚本注入到目标网站的数据库中（如评论区、用户资料、留言板等可提交

• 典型场景：论坛评论、电商商品评价、用户个人签名。

1. 反射型XSS（非持久型XSS，最常见）

• 攻击流程：攻击者构造包含恶意脚本的URL → 诱导用户点击该URL → 目标网站将URL中的恶意脚

本作为参数读取并直接输出到页面 → 脚本被执行。

• 特点：恶意脚本不存储在服务器，仅存在于攻击URL中，需用户主动点击才能触发，危害相对存储

型较小，但传播范围广。

• 典型场景：搜索框、URL参数展示页面（如错误提示页、用户信息查询页）。

1. DOM型XSS（基于DOM的XSS，前端漏洞）

• 攻击流程：攻击者构造包含恶意脚本的URL → 用户点击后，目标网站的前端JavaScript代码从URL

中读取参数并通过DOM操作插入到页面中 → 脚本被执行。

• 特点：恶意脚本从未经过服务器端，完全由前端DOM操作触发，属于前端代码漏洞，与服务器端无

关。

• 典型场景：前端通过location.href、document.cookie等获取数据并直接插入页面。

二、防止XSS攻击的核心方案（前端+后端协同防护）

XSS攻击的本质是「恶意脚本被浏览器解析执行」，防护的核心原则是「让注入的恶意脚本无法被解析为可执行的代码」，需从输入过滤、输出编码、前端DOM防护、Cookie安全等多个维度入手，前端和

后端共同配合。

1. 核心防护：输入过滤与输出编码（后端为主，前端为辅）

• 输入过滤：对用户提交的所有数据（如评论、URL参数、用户资料）进行合法性校验，过滤或拒绝

包含恶意脚本的内容。

• 方案1：白名单过滤（推荐）：仅允许合法的字符/标签（如仅允许字⺟、数字、常用标点，或仅

允许<b>、<i>等安全HTML标签），过滤所有其他非法内容。

• 方案2：黑名单过滤（补充）：禁止包含<script>、alert()、eval()、onclick、onload等恶意关键

词，需注意黑名单易被绕过（如变异脚本<scr输出编码：将从服务器读取的数据输出到页面时，对特殊字符进行HTML编码（或JS编码、URL编码），将恶意脚本转换为普通文本，使其无法被浏览

器解析执行。

• HTML编码：将<、>、&、"、'等特殊字符转换为对应的实体编码（如<→&lt;、>→&gt;），适用

于将数据插入HTML标签内（如<div>{{ 编码后的数据 }}</div>）。

• JS编码：将数据插入JavaScript代码中时（如var data = "{{ 编码后的数据 }}";），需对数据进行

• 避免使用直接插入HTML的危险DOM API：禁止使用document.write()、document.writeln()、

• 示例：
• 危险：document.getElementById("content").innerHTML = untrustedData;（可能注入恶

意脚本）

• 安全：document.getElementById("content").textContent = untrustedData;（仅显示文

本）

• 若必须使用innerHTML：对插入的内容进行严格的HTML编码，或使用成熟的富文本编辑器（如

TinyMCE、Quill），这类编辑器自带XSS过滤功能。

• 避免从URL参数、document.cookie中直接获取数据并插入页面：若需使用，先对数据进行编码处

理。

1. Cookie安全配置（防止XSS窃取Cookie）

• 设置HttpOnly属性：后端在设置Cookie时，添加HttpOnly标识（如Set-Cookie: sessionId=xxx;

HttpOnly），使Cookie无法被JavaScript的document.cookie获取，从根本上防止XSS窃取 Cookie。

• 设置Secure属性：仅允许Cookie在HTTPS协议下传输，避免在HTTP协议下被窃取。

• 设置SameSite属性：限制Cookie仅在同源请求中携带（如SameSite=Strict或SameSite=Lax），

防止跨站请求伪造（CSRF），同时也能辅助防护XSS。

1. 其他辅助防护措施

• 启用Content-Security-Policy（CSP，内容安全策略）：通过HTTP响应头（如Content-Security-

Policy: default-src 'self'; script-src 'self'）限制页面可加载的资源来源，禁止加载外部恶意脚本，即使注入了恶意脚本也无法执行。CSP是防御XSS的强力手段，推荐生产环境启用。

• 使用安全的开发框架：主流前端框架（React、Vue、Angular）默认会对模板中的数据进行HTML

编码，自动防护XSS（如React的JSX语法、Vue的{{ }}插值），但需避免使用 dangerouslySetInnerHTML（React）、v-html（Vue）等危险指令，若使用需手动编码。

• 定期安全检测：使用自动化工具（如OWASP ZAP）扫描网站的XSS漏洞，及时修复问题；对用户

提交的内容进行日志记录，便于追踪攻击行为。

三、总结：XSS防护的核心要点

XSS防护需遵循「前端防御为辅，后端防御为主，协同防护」的原则：后端负责输入过滤和输出编码，从源头阻断恶意脚本注入；前端负责DOM操作防护，避免前端漏洞触发XSS；同时通过Cookie安全配

置和CSP，进一步提升防护等级。最关键的是「不要信任任何用户输入」，对所有不可信数据都进行严格的校验和编码。