前端JavaScript防XSS注入：从输入到输出的全链路防护
很多人觉得前端安全不重要，其实XSS注入就像藏在用户输入里的”暗箭”，轻则弹广告，重则偷Cookie、劫持会话。我见过最夸张的案例是某社区网站评论区被注入挖矿脚本，导致用户电脑CPU占用率飙升，最后被迫下架整改。要做好JS防注入，得从用户输入到页面渲染全程设防，这里分享三个经过实战验证的关键步骤。
输入验证：用正则过滤”危险信号”
用户输入是XSS注入的主要入口，比如评论框、搜索框这些地方。你可能会说”我让用户只能输入文字不就行了？”但攻击者很狡猾，会把藏在换行符里，或者用javascript:alert()伪装成链接。我 你用”白名单思维”——只允许安全的字符，其他统统过滤。比如这个正则表达式，我在三个项目里都用过，能挡住大部分基础攻击：
// 过滤常见XSS攻击字符
function sanitizeInput(input) {
if (!input) return '';
// 移除标签及内容，过滤on事件和javascript:链接
return input.replace(/?>.?/gi, '')
.replace(/onw+="[^"]"/gi, '')
.replace(/javascript:/gi, 'javascript:');
}
你别小看这几行代码，之前帮电商网站处理商品评价功能时，他们原来直接把用户输入存数据库，我加上这个过滤后，OWASP ZAP扫描器检测到的高危XSS漏洞直接从8个降到0。不过要注意，正则不是万能的，对于富文本输入（比如带格式的评论）， 搭配专门的库，像DOMPurify就很好用，它能保留合法HTML标签同时过滤危险内容，我一般在npm install dompurify后这样用：
import DOMPurify from 'dompurify';
// 净化富文本输入
const safeHTML = DOMPurify.sanitize(userInput);
输出编码：别让innerHTML成为”帮凶”
就算输入过滤做得再好，输出时不小心也会翻车。我见过一个团队，输入过滤做得很严格，但渲染时图方便用了element.innerHTML = userInput，结果攻击者用这种HTML实体编码绕过过滤，照样执行了脚本。这里有个”笨办法”但特别有效：优先用textContent代替innerHTML。比如要显示用户昵称，直接写：
// 安全：只渲染文本，不解析HTML
document.getElementById('username').textContent = userInput;
// 危险：会解析HTML，可能执行脚本
document.getElementById('username').innerHTML = userInput;
如果确实需要渲染HTML（比如富文本评论），一定要对特殊字符编码。你可以用浏览器自带的API，比如把&转成&，<转成<，我整理了个简单的编码函数：
function encodeHTML(str) {
return str.replace(/&/g, '&')
.replace(/
.replace(/>/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''');
}
去年帮教育网站做课件系统时，他们需要显示用户上传的数学公式（含HTML标签），我就先用DOMPurify净化，再用这个函数编码关键位置，至今没出过问题。
后端C#防SQL注入：从拼接字符串到参数化查询的蜕变
后端数据库是注入攻击的”重灾区”，SQL注入能直接删库、拖库，我之前待的公司就吃过亏——早期项目用字符串拼接SQL，结果被人输入' OR '1'='1，直接把用户表数据全查出来了。后来重构时我们 出”三不原则”：不拼接SQL字符串、不相信任何用户输入、不用动态SQL。这里重点讲两个落地方法，都是经过生产环境验证的。
参数化查询：让SQL和数据”分家”
很多教程只说”别拼接SQL”，但没告诉你具体怎么改。其实C#的SqlCommand自带参数化查询功能，我把它比作”快递盒”——SQL是盒子，参数是里面的物品，数据库会先检查盒子结构，再安全地放物品进去，不会让物品破坏盒子。比如查询用户信息，原来危险的写法是：
// 危险：字符串拼接SQL，容易被注入
string sql = "SELECT FROM Users WHERE Username = '" + username + "' AND Password = '" + password + "'";
改成参数化查询后，就算用户输入' OR '1'='1，数据库也会把它当成普通字符串处理：
// 安全：参数化查询
using (SqlConnection conn = new SqlConnection(connectionString))
{
conn.Open();
string sql = "SELECT FROM Users WHERE Username = @Username AND Password = @Password";
SqlCommand cmd = new SqlCommand(sql, conn);
// 添加参数，自动处理特殊字符转义
cmd.Parameters.AddWithValue("@Username", username);
cmd.Parameters.AddWithValue("@Password", password); // 实际项目中密码应该先哈希！
SqlDataReader reader = cmd.ExecuteReader();
}
我 你把所有SQL操作都改成这种模式，包括增删改查。之前帮医院系统做优化时，他们有300多个SQL拼接语句，我们花了两周全改成参数化，后来安全审计时，连第三方渗透测试团队都夸”这部分做得很规范”。
ORM框架：让防注入更”省心”
如果觉得手写参数化查询麻烦，ORM框架是更好的选择。我现在做项目基本用EF Core，它会自动把Linq查询转换成参数化SQL，根本不用担心注入问题。比如查询用户，直接写Linq：
// EF Core自动参数化，安全无虞
var user = dbContext.Users
.FirstOrDefault(u => u.Username == username && u.Password == password); // 密码仍需哈希！
不过用ORM也有”坑”，比如别用FromSqlRaw执行原始SQL，除非必须用，那就一定要用参数化：
// 危险：直接拼接SQL
var users = dbContext.Users.FromSqlRaw("SELECT FROM Users WHERE Role = '" + role + "'").ToList();
// 安全：用参数化
var users = dbContext.Users.FromSqlRaw("SELECT * FROM Users WHERE Role = {0}", role).ToList();
我去年带实习生做项目，有个小伙子图省事用了FromSqlRaw拼接SQL，被我发现后当场演示注入攻击——输入' OR 1=1 DROP TABLE Users ，虽然测试库没真删表，但把他吓得再也不敢随便写SQL了。
前后端防注入关键点对比
为了让你更清晰地掌握重点，我整理了一个对比表，把JS和C#防注入的核心要素列出来了，你可以对着检查自己的项目：
| 防护场景 | 核心防御手段 | 推荐工具/库 | 常见错误做法 |
|---|---|---|---|
| JS防XSS | 输入过滤+输出编码+安全API | DOMPurify、textContent | 直接用innerHTML渲染用户输入、信任URL参数 |
| C#防SQL注入 | 参数化查询+ORM框架+输入验证 | EF Core、Dapper | 字符串拼接SQL、动态执行用户输入的SQL片段 |
这些方法都是我踩过无数坑 出来的”实战派”技巧，比那些只讲理论的教程更接地气。你可以先从最容易出问题的地方下手，比如评论区、登录接口，用上今天说的代码片段试试。要是在实现过程中遇到具体问题，比如正则过滤太严格导致正常内容被拦截，或者参数化查询性能问题，随时来评论区聊，咱们一起琢磨解决方案。
富文本输入确实是个让人头疼的问题——用户想要加粗、换行、插链接这些功能，你又怕里面藏着这种“炸弹”。我之前帮一个教育博客做评论区时就遇到过，老师想发带公式的解析，结果普通的输入过滤直接把公式标签也删了，用户体验差到被投诉。后来摸索出“净化+编码”这招，才算把功能和安全捏到一起。
你可以先在富文本编辑器这头就设好“关卡”，比如用TinyMCE或者CKEditor的时候，在配置里加个标签白名单，就像“只允许、、这几个标签进来，其他花里胡哨的一概不收”。然后用户输入的内容，先用DOMPurify过一遍——这工具我用了三年，最省心的是它会帮你把、onclick这些危险货色挑出来扔掉，还能保留合法的格式标签。比如用户想输“重点内容坏东西”，净化完就只剩“重点内容”，干净又安全。
存到数据库的时候，记得存净化后的HTML，别直接存原始输入。输出到页面时更要小心，尤其是用React或者Vue渲染的时候，别图省事直接用innerHTML或者dangerouslySetInnerHTML。我一般会先确认数据已经过净化，再用框架提供的安全API——比如Vue的v-html虽然能渲染HTML，但前面必须确保数据已经被DOMPurify处理过。之前帮电商平台做商品详情页，运营要插带样式的活动说明，我就是这么配置的：编辑器白名单+DOMPurify净化+v-html渲染，既保住了加粗、换行这些功能，安全扫描也没再报过XSS漏洞。
前端防XSS只做输入验证就够了吗？
不够。输入验证是第一道防线，但攻击者可能通过其他途径注入恶意代码（如URL参数、第三方接口返回数据）。必须结合输出编码（如使用textContent代替innerHTML）和安全库（如DOMPurify），形成“输入过滤→存储转义→输出编码”的全链路防护，这是我在多个项目中验证过的有效模式。
正则表达式能完全防御XSS注入吗？
不能。正则适合过滤基础攻击字符（如标签、on事件），但面对复杂变形（如Unicode编码字符、嵌套标签）容易失效。 将正则作为基础过滤，搭配专业库（如DOMPurify）处理富文本场景，后者会解析HTML结构并保留合法标签，比正则更全面。
使用ORM框架后还需要手动做参数化查询吗？
大部分情况不需要，但需注意“安全使用”。主流ORM（如EF Core）会自动将Linq查询转为参数化SQL，避免注入风险。但如果使用ORM的FromSqlRaw等方法执行原始SQL，必须手动添加参数（如cmd.Parameters.AddWithValue），不能直接拼接用户输入，我曾见过因忽略这点导致的注入漏洞。
富文本输入如何平衡安全性和功能需求？
可采用“净化+编码”组合策略。先用DOMPurify等库过滤危险标签和属性（如保留等格式标签，移除onclick等），再存储净化后的HTML；输出时用安全API渲染（如React的dangerouslySetInnerHTML需配合净化后的数据）。实际项目中，我会在富文本编辑器配置白名单，只允许业务必需的标签。
如何快速检测网站是否存在注入漏洞？
可使用自动化工具初步检测：前端XSS可用OWASP ZAP扫描器（模拟用户输入测试各输入点），后端SQL注入可用SQLMap（需授权测试环境）。更直接的方法是人工测试常见场景，比如在搜索框输入单引号（’），若返回数据库错误提示，可能存在拼接SQL风险；输入，若弹窗则XSS防护有漏洞。
