在 Web 安全领域，浏览器安全模型是理解一切前端攻击与防御的起点。其中，跨站脚本攻击（XSS）常年位居 OWASP Top 10 之列，是前端开发者必须掌握的核心安全议题。本文将从浏览器的同源策略出发，系统梳理 XSS 的常见方式与前端防御手段，并延伸讨论后端相关的 SQL 注入防护与 Linux 服务器安全加固，帮助开发者建立纵深防御的思维。
一、浏览器安全模型的核心：同源策略
同源策略（Same-Origin Policy）是浏览器最基础的安全机制。它规定：只有协议、域名、端口三者完全一致，两个页面才属于“同源”，才能相互读取 DOM、Cookie、LocalStorage 等资源。这一策略有效阻止了恶意网站直接读取用户在其他站点上的敏感数据。
然而，同源策略并非万能。它主要限制“读取”操作，而 XSS 攻击恰恰是利用了“注入并执行”这一能力——攻击者将恶意脚本注入到受信任的页面中，使脚本在目标站点的源下运行，从而绕过同源策略的限制。
此外，浏览器还提供了 CSP（内容安全策略）、CORS（跨域资源共享）、HttpOnly Cookie 等机制，共同构成纵深防御体系。理解这些机制的边界，是防御 XSS 的前提。
二、XSS 的常见方式
XSS 攻击的本质是：用户输入的数据被当作代码执行。根据注入方式和持久性，通常分为三类。
1. 反射型 XSS
恶意脚本作为请求参数发送给服务器，服务器未经充分处理便将其“反射”回响应页面中。例如：
https://example.com/search?q=<script>alert(document.cookie)</script>
如果搜索页面直接将该参数输出到 HTML 中，脚本就会在用户浏览器中执行。反射型 XSS 通常需要诱导用户点击恶意链接。
2. 存储型 XSS
恶意数据被持久化存储在服务器端（如数据库、评论、用户资料），当其他用户访问该页面时自动触发。例如，攻击者在评论区提交包含恶意脚本的内容，所有查看该评论的用户都会中招。存储型 XSS 危害最大，因为它无需诱导点击，影响面广。
3. DOM 型 XSS
攻击载荷不经过服务器，完全由前端 JavaScript 处理不当造成。例如：
document.getElementById('output').innerHTML = location.hash.slice(1);
如果 URL 为 #<img src=x onerror=alert(1)>，脚本就会在 DOM 中被执行。DOM 型 XSS 的防御重点在于前端代码本身。
三、前端如何防御 XSS
防御 XSS 的核心原则是：永远不要信任用户输入，对输出进行恰当的编码。以下是前端可落地的具体措施。
1. 输出编码
根据输出位置选择正确的编码方式：
- HTML 上下文：将
& < > " '转义为 HTML 实体。 - JavaScript 上下文：使用
JSON.stringify或 Unicode 转义。 - URL 上下文：使用
encodeURIComponent。 - CSS 上下文：避免将用户输入放入 CSS，必要时进行严格白名单过滤。
2. 避免危险的 DOM API
优先使用 textContent 而非 innerHTML。如果必须使用 innerHTML，务必先经过 DOMPurify 等成熟库净化。避免使用 eval、Function、document.write 等动态执行代码的 API。
3. 使用内容安全策略（CSP）
CSP 通过 HTTP 响应头限制脚本来源，例如：
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none'
这能有效阻止内联脚本和未授权外部脚本的执行，是抵御 XSS 的最后一道防线。
4. 设置 HttpOnly 与 Secure Cookie
将敏感 Cookie 标记为 HttpOnly，使 JavaScript 无法读取；标记为 Secure，确保仅通过 HTTPS 传输。这能降低 XSS 成功后窃取会话的风险。
5. 框架自带防护
现代前端框架（React、Vue、Angular）默认对插值进行转义。但要注意 dangerouslySetInnerHTML、v-html 等逃生舱口，使用前必须净化内容。
四、MySQL 防止 SQL 注入的几种写法
虽然 SQL 注入属于后端范畴，但前后端安全密不可分。以下是 PHP 中常见的防护写法（其他语言思路一致）。
错误写法（拼接字符串）：
$sql = "SELECT * FROM users WHERE name = '" . $_GET['name'] . "'";
正确写法一：预处理语句（PDO）
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$_GET['name']]);
正确写法二：命名占位符
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $_GET['name']]);
正确写法三：mysqli 预处理
$stmt = $mysqli->prepare("SELECT * FROM users WHERE name = ?");
$stmt->bind_param("s", $_GET['name']);
$stmt->execute();
核心原则：永远不要将用户输入直接拼接到 SQL 语句中。预处理语句将 SQL 结构与数据分离，是防御 SQL 注入最有效的手段。
五、Linux 服务器安全加固清单
服务器是 Web 应用的运行基座，加固清单如下：
- 及时更新系统与软件：定期执行
apt update && apt upgrade或yum update，修补已知漏洞。 - 最小化服务：关闭不必要的端口和服务，使用
ss -tulnp检查监听端口。 - SSH 加固：禁用 root 远程登录，使用密钥认证，修改默认端口，配置
Fail2Ban防暴力破解。 - 防火墙配置：使用
ufw或iptables仅放行必要端口（如 80、443）。 - 最小权限原则：Web 服务以独立低权限用户运行，数据库用户仅授予必要权限。
- 日志与监控：启用
auditd，定期检查/var/log/auth.log、/var/log/nginx/access.log。 - 文件权限：敏感文件设为
600，目录设为750，避免全局可写。 - 备份与恢复：定期备份关键数据，并验证恢复流程。
结语
浏览器安全模型、XSS 防御、SQL 注入防护与服务器加固，共同构成 Web 安全的纵深防线。前端开发者不应只关注页面交互，更需理解同源策略、输出编码与 CSP 的运作方式；后端与运维同样需要落实预处理语句与系统加固。安全不是某一个环节的事，而是贯穿整个技术栈的持续实践。唯有如此，才能在日益复杂的威胁环境中守住用户与数据的底线。
未经允许不得转载：任鹏个人博客 » 浏览器安全模型与前端 XSS 防御基础
朋友圈点赞图在线生成源码
