浏览器地址栏里敲下一段代码，注入页面瞬间变了样。注入这不是注入什么黑客电影，只是注入JS注入最朴素的形态——在别人家的页面上，跑自己的注入代码。

我试过一次。注入把购物网站的注入价格标签全改成"免费"，截图发给朋友，注入他信了，注入激动地问链接。注入这玩笑开得低级，注入但足够说明问题：前端页面对JS完全敞开，注入你塞什么，注入它就执行什么。注入没人拦着。注入

真正的JS注入比改价格危险得多。攻击者不需要访问你的服务器，不需要破解数据库，只需要找到一处没过滤的输入框。评论区、搜索框、URL参数，都是入口。往里面塞一段script标签，代码就顺着页面流进每个访客的浏览器。你只是看了篇文章，电脑就替别人发了请求，转了账，改了密码。整个过程无声无息，浏览器地址栏还是那个地址，页面看起来还是那个页面。

XSS，跨站脚本攻击，这是JS注入最臭名昭著的分支。它的狡猾在于不直接攻击网站，而是攻击网站的用户。网站成了传话筒，恶意代码披着合法域名的外衣，骗过浏览器的同源策略。你在bank.com的页面上执行了一段脚本，浏览器以为这是银行自己发的指令，乖乖交出cookie。就这么简单。

存储型XSS更阴险。攻击者把恶意脚本存在服务器上，谁打开那个页面谁中招。论坛签名档里藏代码，个人资料页里埋雷，等管理员登录后台，脚本在管理员的浏览器里跑起来，整个站点的控制权就换了主人。2005年Samy蠕虫就是这么干的，MySpace上一个叫Samy的年轻人往自己资料里塞了段代码，任何人浏览他的页面就会自动把他加为好友，然后复制这段代码到自己资料里。一天之内，百万用户中招。

反射型XSS则是钓鱼的好帮手。攻击者把恶意链接发给受害者，链接里带着参数，参数里藏着脚本。受害者点开，脚本在打开的页面里执行。这类攻击需要受害者主动配合，但配合并不难——把链接伪装成"查看您的账户异常"，很多人就点了。

DOM型XSS不碰服务器，纯粹在浏览器端作祟。页面自己用innerHTML拼接数据，用户输入直接进DOM，脚本就活了。前端框架越用越多，这类漏洞反而更容易出现，因为开发者默认框架会处理安全问题，结果框架只管自己的渲染逻辑，不管你在v-html里塞了什么。

防御手段听起来都挺硬核：转义输出、CSP白名单、HttpOnly cookie、输入校验。但真正的问题不在技术，在认知。很多开发者觉得"我这是内部系统，没人会攻击"。内部系统里存着工资单，存着客户手机号，存着比公开页面更敏感的数据。而且内部系统往往疏于防护，攻破一个内部小工具，可能就顺着内网漫游到核心服务器。

我见过最离谱的一次，是某后台管理系统的搜索框直接拼SQL，前端把用户输入的引号原样传给后端。这已经不是JS注入的问题了，是SQL注入。但两者思路一致：信任用户输入，就要付出代价。

写代码的人得明白，浏览器是个危险的地方。你打开的每个页面，都可能带着别人的意图。JS注入的可怕之处在于它太容易发生，又太容易被忽略。一行代码没转义，一个属性没加引号，漏洞就埋下了。它不像SQL注入那样需要复杂的数据库知识，也不像缓冲区溢出那样需要汇编功底。只要HTML里允许写script，只要JavaScript能操作DOM，注入就永远有缝可钻。

下次你在控制台里粘贴一段网上找的代码时，想想它会在你当前页面上做什么。你信任的那段代码，可能正悄悄把你的cookie发到某个服务器。JS注入离我们不远，它就藏在你每天打开的页面里，藏在每个没被过滤的输入框里，藏在你随手粘贴的那段代码里。