前端安全防御清单：从 XSS 到依赖风险

前端早已不是“切图仔”的专属领地。随着 SPA、SSR、微前端以及 npm 生态的爆炸式增长，前端工程师手中掌握的用户数据、接口权限和构建链路，都成了攻击者眼中的高价值目标。这篇文章整理了一份可落地的前端安全防御清单，涵盖 XSS、SQL 注入的边界认知、服务器加固以及依赖风险，帮助你从代码到部署建立完整的防护视角。

一、XSS 的常见方式与前端防御

XSS（跨站脚本攻击）仍然是前端最直接、最频繁的安全威胁。攻击者通过注入恶意脚本，在用户浏览器中执行，从而窃取 Cookie、Token、篡改页面或发起蠕虫攻击。

1.1 三种常见类型

• 存储型 XSS：恶意脚本被存入数据库（如评论、用户昵称），所有访问该页面的用户都会中招。危害最大，常见于论坛、社交平台。
• 反射型 XSS：恶意脚本作为请求参数发给服务器，服务器直接“反射”回 HTML 中。通常需要诱导用户点击恶意链接。
• DOM 型 XSS：完全发生在浏览器端，前端 JS 从 location.hash、document.referrer 等来源取数据并直接插入 DOM，不经过服务器。

1.2 前端防御核心手段

① 输出编码，而非输入过滤

很多开发者习惯在输入时过滤 <script>，但攻击者可以用 <img src=x onerror=alert(1)> 绕过。正确的做法是在输出到不同上下文时进行编码：

• HTML 上下文：将 & < > " ' 转义为实体。
• JS 上下文：使用 JSON.stringify 并避免直接拼接。
• URL 上下文：使用 encodeURIComponent。

② 使用安全的 DOM API

避免 innerHTML、outerHTML、document.write。如果必须渲染富文本，使用 DOMPurify 等库进行白名单过滤：

import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userInput);
element.innerHTML = clean;

③ 启用 CSP（内容安全策略）

CSP 是 XSS 的“最后一道防线”。通过 HTTP 头限制脚本来源：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none';

避免使用 unsafe-inline 和 unsafe-eval。对于现代框架，尽量使用 nonce 或 hash 方式。

④ 设置 HttpOnly 和 SameSite Cookie

即使 XSS 发生，HttpOnly 能防止 JS 读取敏感 Cookie；SameSite=Lax/Strict 能缓解 CSRF 和部分数据泄露。

二、MySQL 防止 SQL 注入的几种写法

严格来说，SQL 注入属于后端和数据库层面的问题，但前端工程师在联调、写 BFF 层或 Node.js 中间层时，同样可能直接拼接 SQL。以下是几种正确的防御写法。

2.1 参数化查询（预编译语句）——首选

-- 错误：字符串拼接
SELECT * FROM users WHERE email = '${email}';

-- 正确：参数化查询
SELECT * FROM users WHERE email = ?;

在 Node.js 的 mysql2 中：

const [rows] = await connection.execute(
  'SELECT * FROM users WHERE email = ? AND status = ?',
  [email, status]
);

参数化查询让数据库将输入视为数据而非 SQL 代码，从根本上杜绝注入。

2.2 使用 ORM 或查询构建器

Sequelize、TypeORM、Knex 等默认使用参数化绑定。但要注意：不要用 ORM 的“原始查询”方法拼接用户输入，例如 sequelize.query(\SELECT * FROM ${table}`)` 依然危险。

2.3 输入验证与最小权限

• 对邮箱、ID、排序字段等做白名单校验。例如 ORDER BY 后的字段不能参数化，只能用白名单映射。
• 数据库账号遵循最小权限原则：Web 应用账号不应有 DROP、FILE、GRANT 权限。

2.4 转义——仅作补充

mysql.escape() 可以转义特殊字符，但容易遗漏，不应作为主要防御手段。参数化查询才是标准答案。

三、Linux 服务器安全加固清单

前端项目最终要部署在服务器上。以下加固措施适用于 Nginx + Node.js 的典型前端部署环境。

3.1 账户与 SSH

• 禁用 root 远程登录：PermitRootLogin no。
• 使用密钥登录，禁用密码认证：PasswordAuthentication no。
• 修改默认 SSH 端口，减少自动化扫描。
• 使用 fail2ban 自动封禁暴力破解 IP。

3.2 防火墙与端口

• 仅开放 80、443 和必要的 SSH 端口。
• 使用 ufw 或 firewalld 设置默认拒绝策略。
• 数据库（MySQL）、Redis 等只监听 127.0.0.1，不暴露公网。

3.3 系统更新与最小化安装

• 定期执行 apt update && apt upgrade 或 yum update。
• 卸载不必要的服务（如 FTP、Telnet）。
• 使用 unattended-upgrades 自动安装安全补丁。

3.4 Web 服务器与 Node 进程

• Nginx 配置安全响应头：X-Content-Type-Options、X-Frame-Options、Referrer-Policy。
• Node 进程不要以 root 运行，使用 pm2 或 systemd 指定非特权用户。
• 限制请求体大小，防止 DoS：client_max_body_size 10m;。
• 隐藏版本号：server_tokens off;。

3.5 日志与监控

• 开启 Nginx 访问日志和错误日志，并定期轮转。
• 使用 auditd 监控敏感文件变更。
• 配置告警：异常登录、CPU 突增、大量 4xx/5xx。

四、依赖风险：被忽视的供应链攻击

前端项目动辄几百个 npm 包，任何一个包被投毒或存在漏洞，都可能让整个应用沦陷。event-stream、ua-parser-js、colors 等事件已经反复敲响警钟。

4.1 依赖审计

• 定期运行 npm audit 或 yarn audit，修复高危漏洞。
• 使用 npm audit fix 时注意不要盲目升级破坏兼容性。
• 在 CI 中集成 audit 步骤，阻止高危依赖合并。

4.2 锁定版本与完整性

• 提交 package-lock.json 或 yarn.lock，确保构建可复现。
• 使用 npm ci 而非 npm install 进行 CI 构建。
• 启用 npm config set ignore-scripts true，防止安装时执行恶意脚本（按需开启）。

4.3 使用 SCA 与 SBOM

• 采用 Snyk、Dependabot、Renovate 等工具自动扫描和升级。
• 生成 SBOM（软件物料清单），清楚知道每个依赖的来源和版本。

4.4 减少依赖数量

• 评估每个新依赖的必要性。一个 left-pad 式的工具函数完全可以自己写。
• 优先选择维护活跃、下载量大、无已知漏洞的包。
• 对于关键路径，考虑锁定到具体 commit 或使用私有 registry 代理。

结语

前端安全不是一次性的任务，而是一条从浏览器到数据库、从代码到服务器的完整防线。XSS 防御靠输出编码和 CSP，SQL 注入靠参数化查询，服务器靠最小权限和持续更新，依赖风险靠审计和克制。把这四块拼在一起，你才真正拥有了一份可落地的前端安全防御清单。

未经允许不得转载：任鹏个人博客 » 前端安全防御清单：从 XSS 到依赖风险