javascript:伪协议必须被拦截，因其可绕过CSP、不触发网络请求、不受同源策略限制，是XSS和钓鱼常用入口；需用URL构造函数解析后校验protocol白名单，并配合标准化清理与服务端双重校验。
为什么 javascript: 伪协议必须被拦截
浏览器遇到 javascript:alert(1) 这类链接时，点击会直接执行 JS，绕过 CSP、不触发网络请求、也不受同源策略限制——这是 XSS 和钓鱼最常用的跳转入口。URL 解析器本身（比如 URL 构造函数）不会拒绝它，new URL('javascript:alert(1)') 能成功创建实例，href、protocol 字段也都正常返回，但此时已埋下风险。
用 URL 构造函数 + 协议白名单做基础过滤
不要只检查字符串是否以 javascript: 开头（容易被 javascript: 或换行绕过），而应依赖浏览器原生解析后的真实 protocol 值做判断：
function isSafeUrl(input) {
try {
const url = new URL(input, 'https://example.com');
return ['http:', 'https:', 'mailto:', 'tel:', 'ftp:'].includes(url.protocol);
} catch {
return false;
}
}注意几点：
-
new URL()第二个参数是 base URL，用于处理相对路径；没它时，纯javascript:...会被当作绝对 URL 解析成功 - 白名单必须显式包含末尾冒号（
https:不是https），否则url.protocol === 'https'永远为 false -
data:和blob:也需按需加入白名单，但它们同样可能携带恶意代码，建议默认排除
服务端校验不能只靠前端 URL 解析
前端过滤可被绕过，服务端必须重复校验。Node.js 中若用 url.parse()（已废弃）或 new URL()，行为与浏览器一致，但要注意：
立即学习“Java免费学习笔记（深入）”；
- 某些旧环境（如 Electron 旧版或低版本 Node）对
javascript:解析不报错，但protocol可能为''或'javascript'（无冒号），需额外兼容 - Python 的
urllib.parse.urlparse()会将javascript:alert(1)解析为ParseResult(scheme='javascript', netloc='', path='alert(1)', ...)，此时只需检查scheme是否在白名单内 - 永远拒绝空
scheme或非字母开头的scheme（如\x00javascript:）
HTML 中 a 标签的 href 需双重防护
即使后端已过滤，用户仍可能通过 DevTools 直接修改 DOM 注入恶意链接。因此渲染前必须再走一次校验：
const safeHref = isSafeUrl(userInput) ? userInput : '#';
element.setAttribute('href', safeHref);更稳妥的做法是：对所有用户可控的链接，统一用 rel="noopener noreferrer" 并禁用 target="_blank" 的隐式权限提升；如果业务允许，优先改用按钮 + 显式事件处理，彻底避开 href 执行上下文。
真正麻烦的不是识别 javascript:，而是它常和编码、注释、空白字符混在一起，比如 java%09script:alert(1) 或 javascript<!-- -->:alert(1)——这些必须在解析前做标准化清理，否则白名单校验形同虚设。
