DeepCode 安全技能库解析：React (JavaScript/TypeScript) 前端安全规范实战指南

DeepCode 安全技能库解析React (JavaScript/TypeScript) 前端安全规范实战指南【免费下载链接】DeepCodeDeepCode: Open Agentic Coding (Agent Harness Loop Engineering Multi-Agent Orchestration)项目地址: https://gitcode.com/GitHub_Trending/deepc/DeepCode导读本文深入解析 DeepCode 开源项目中内置的React 前端安全最佳实践规范对应 core/skills/builtin/security-best-practices/references/javascript-typescript-react-web-frontend-security.md。这份规范以“MUST / SHOULD / MAY”规范性要求加审计规则的形式同时支撑两类工作场景安全默认secure-by-default的代码生成以及对既有 React 代码的安全审查与漏洞狩猎。读完本文你将掌握 18 条带严重级别、检测提示与修复方案的 React 安全规则覆盖 XSS、CSRF、CSP、供应链、认证存储等并了解如何将规则落地到 React 19 TypeScript 5 Vite 的真实项目中——包括 DeepCode 桌面端自身的实践。1. 这份规范在 DeepCode 中的定位在 DeepCode 仓库中该规范是内置技能security-best-practices的参考文档之一。技能本身由 SKILL.md 描述工作流先识别当前上下文的语言与框架Python、JavaScript/TypeScript、Go 等再从references/目录加载对应语言/框架的安全参考文档文件名格式为语言-框架-栈-security.md例如本文主角javascript-typescript-react-web-frontend-security.md然后以三种模式工作生成模式写新代码时默认遵循、被动审查模式编辑代码时顺带发现安全问题、主动审计模式用户明确要求扫描/审计时输出结构化漏洞报告。技能目录下还包含 golang-general-backend-security.md、python-fastapi-web-server-security.md 等十余份同类参考文档以及配套的 agents/openai.yaml。从 UPSTREAM_SOURCES.json 可以看出该技能来自开源生态openai/skills的策展技能集DeepCode 将其内置为开箱即用的安全能力。这份 React 规范的适用对象很具体React 19.x TypeScript 5.x的前端代码。而 DeepCode 桌面端desktop/正是这样一个真实消费者其 package.json 使用 React 19react ^19.2.7、Vite 8、TypeScript本规范中的大量规则可以在其中找到对应实践详见第 6 节。2. 安全边界、反滥用约束与三种工作模式2.1 必须遵守的安全边界§0规范开篇给出四条不可逾越的约束它们是所有规则的前提绝不请求、输出、记录或提交密钥API Key、OAuth client secret、私钥、会话 Cookie、JWT、签名密钥。前端尤其特殊任何送到浏览器的内容view-source、devtools、代理抓包对用户和攻击者都可见永远不要把客户端代码或“打包进 bundle 的 env 变量”当作秘密。绝不通过“关闭防护”来“修复”安全问题——例如为了跑通功能关掉 CSP、无约束地添加unsafe-inline/unsafe-eval、在使用 Cookie 认证时禁用 CSRF 防护、放宽 CORS、跳过净化、或把“临时”绕过方案带上生产。审计时必须提供基于证据的发现引用文件路径、代码片段与配置值来支撑结论。对不确定性要诚实如果某项防护可能存在于基础设施层CDN/WAF/反向代理应报告为“应用代码中不可见请通过运行时响应头/边缘配置验证”。此外还有一个贯穿全文的核心假设§2.1任何跨越信任边界的数据URL、存储、网络、postMessage、第三方脚本在未被证明安全之前一律视为可被攻击者控制。2.2 生成模式默认当被要求编写新的 React 代码或修改既有代码时必须遵循规范中每一条MUST要求应当遵循每一条SHOULD要求除非用户明确反对必须优先选择默认安全的 API 与久经验证的库而非自研安全代码必须避免引入新的风险型代码路径raw HTML 插入、innerHTML等直接 DOM 写入点、动态代码执行、不可信重定向/导航、第三方脚本注入、不安全的令牌存储等。2.3 被动审查模式编辑时始终开启即使没有被要求做安全扫描在处理 React 仓库任意位置代码时也必须“留意”被触碰或相邻代码中的规范违例并在发现时给出简短解释与安全修复建议。2.4 主动审计模式显式扫描请求当用户要求“扫描 / 审计 / 找漏洞”时必须系统性搜索代码库中的违例并按照结构化格式输出发现见 §2.3 审计格式。规范推荐如下审计顺序应用入口、构建工具Vite/Webpack/CRA/Next、部署配置、CDN/静态托管配置密钥与配置暴露env 变量、运行时配置注入、source map不可信数据渲染XSS/DOM XSS重点看dangerouslySetInnerHTML、markdown/HTML 渲染器、URL 属性直接 DOM 操作与危险 JS 执行innerHTML、eval、new Function、document.write等认证与会话模式令牌存储、Cookie、CSRF 交互、OAuth 流程网络层axios/fetch 封装、动态 baseURL、携带凭据的请求、数据外泄风险导航与重定向处理开放重定向、window.location、target_blank、window.open第三方脚本/标签/分析与完整性控制CSP、SRIService Worker / PWA 行为HTTPS、缓存规则、更新策略安全响应头姿态CSP、防点击劫持、nosniff、Referrer Policy——在应用内或边缘层。2.5 审计发现的标准格式§2.3每条发现必须包含以下字段确保可验证、可追溯、可修复Rule ID规则编号SeverityCritical / High / Medium / LowLocation文件路径 组件/函数 行号Evidence确切的代码/配置片段Impact可能造成什么后果、谁能利用Fix安全的修改方案优先最小 diffMitigation难以立即修复时的纵深防御手段False positive notes不确定时应核验哪些点侧记规范还给出了前端视角的“状态变更请求”定义§2.2——凡能创建/更新/删除数据、改变认证/会话状态、触发副作用下单、发邮件、webhook或发起特权操作的请求均为状态变更请求若使用 Cookie 认证这类请求与 CSRF 相关对应规则 REACT-CSRF-001。3. 生产基线最小化生产配置MUST这是防止常见 React 前端错误配置的“最小生产基线”分三层3.1 生产构建与配置卫生MUST必须发布生产构建压缩、无 dev 专属浮层/工具、正确的 mode 标志必须确保构建期配置不把密钥嵌入最终交付的 JS/HTML/CSS。构建期“环境变量”不是秘密一律视为公开数据应当把source map当作敏感运维产物要么不公开发布要么只发布到预期位置如鉴权保护后或错误上报服务因为它们会暴露代码结构与内部 URL。3.2 浏览器强制防护SHOULD但现代应用的基线期望应当部署CSP作为针对 XSS 的纵深防御并保持与 React 构建兼容除非确有必要且有文档记录否则避免unsafe-inline与unsafe-eval对从 CDN 加载的第三方脚本/样式应当使用Subresource IntegritySRI或改为自托管应当通过 CSP 的frame-ancestors和/或X-Frame-Options启用防点击劫持除非嵌入是明确的产品需求。3.3 高危功能基线若使用则为 MUST若渲染任何用户提供的 HTML/markdown/富文本插入前必须净化并避免直接 DOM 写入点若使用 Service Worker / PWA必须通过 HTTPS 提供并实现安全的缓存/更新策略Service Worker 是能力很强的请求/响应代理。4. 规则体系详解生成 审计规范的核心是 18 条带编号的规则每条均包含必需实践、不安全模式、检测提示、修复方案。下面按风险域分组逐一展开。4.1 配置与密钥泄露REACT-CONFIG-001绝不把密钥嵌入客户端 bundleenv 变量是公开的严重级别Critical一旦密钥暴露必需不得将密钥放入 React 代码、public/静态资源或面向客户端的构建期环境变量必须假设运行时能访问到的任何值都可被攻击者提取。不安全模式用构建期 env 变量存密钥process.env.REACT_APP_*包含私钥或凭据、import.meta.env.VITE_*包含密钥JS/TS 中硬编码密钥、提交.env、或在所有人可见的public/config.json中放密钥。检测提示搜索REACT_APP_、VITE_、NEXT_PUBLIC_、process.env.、import.meta.env.以及apiKey、secret、token、private、password、client_secret检查public/下的运行时配置 JSON。修复将密钥移到服务端API、BFF、serverless 函数若浏览器确需调用第三方 API由后端签发短期、受限作用域的令牌。依据CRA 官方明确警告不要存储密钥env 变量会被嵌入构建产物、任何人检视文件即可看到Vite 官方同样注明暴露给客户端代码的变量会进入客户端 bundle不应包含敏感信息。4.2 XSS 与渲染安全REACT-XSS-001不得对不可信内容使用dangerouslySetInnerHTML净化或避免严重级别High仅在你能证明攻击者控制的 HTML 能到达该点时必需除非万不得已避免dangerouslySetInnerHTML若必须使用则必须用久经验证的净化器如 DOMPurify并采用白名单导向的配置净化不可信 HTML净化逻辑必须集中维护并重点审查应当叠加 CSP 并考虑 Trusted Types见 REACT-TT-001。不安全模式div dangerouslySetInnerHTML{{ __html: userHtml }} /且userHtml来自 API/URL/存储用正则、临时裁剪或不完整白名单做“净化”。检测提示grepdangerouslySetInnerHTML、__html:追溯 HTML 字符串来源API/CMS/URL/localStorage。修复改为安全渲染——把结构化数据渲染为 React 元素/组件而非 HTML 字符串确实需要富文本时用 DOMPurify 净化后再渲染添加 CSP 并尽可能移除危险写入点。依据React 官方明确警告dangerouslySetInnerHTML使用不当会引入 XSSOWASP 也把“未净化就使用 React 的dangerouslySetInnerHTML”列为常见的框架“逃生舱”陷阱。REACT-XSS-002依赖 React 默认转义行为不要绕过它严重级别High被绕过时必需不可信字符串必须通过常规 JSX 插值{value}与 React props 渲染——React DOM 默认会转义不得用不可信数据拼接 HTML 字符串再以任何方式注入 DOM任何“逃生舱”都应视为高风险并要求审查。不安全模式element.innerHTML userValue、document.write(userValue)、insertAdjacentHTML(..., userValue)。检测提示grep DOM 写入点innerHTML、outerHTML、insertAdjacentHTML、document.write、DOMParser、createContextualFragment。修复通过 ReactJSX渲染文本内容以利用默认转义确需 HTML 时先净化并应用 REACT-XSS-001 REACT-TT-001。REACT-DOM-001避免 React 代码中的 DOM XSS 注入写入点使用安全替代严重级别High必需即使绕过 React 渲染也要避免直接 DOM 注入写入点除非受到严格控制若确需 DOM 写入点必须保证输入可信/已校验/已净化并应当强制 Trusted Types。不安全模式someEl.innerHTML untrusted、document.write(untrusted)、new DOMParser().parseFromString(untrusted, text/html)后插入。检测提示grepinnerHTML、outerHTML、document.write、DOMParser、Range().createContextualFragment、insertAdjacentHTML。修复文本插入优先用textContent优先 React 渲染而非手工 DOM 操作确需 HTML 解析时使用经过验证的净化器。依据MDN Trusted Types 文档将Element.innerHTML、document.write()列为注入写入点OWASP HTML5 指南建议对不可信数据赋值使用textContent而非innerHTML。REACT-MARKUP-001markdown / 富文本渲染必须安全配置严重级别Medium必需若 markdown/富文本来自用户或 CMS必须假设其可被攻击者控制必须确保未净化的原始 HTML 不被渲染应当优先选择默认不允许 raw HTML、或可配置禁止 raw HTML、或在渲染前净化输出的 markdown 渲染器。不安全模式开启“raw HTML 直通”的 markdown 渲染如允许 HTML 的选项/插件未经净化内联渲染用户提供的 SVG/MathML/HTML。检测提示搜索常见库与危险选项marked、markdown-it、react-markdown、rehype-raw、sanitize: false、allowDangerousHtml等警惕用dangerouslySetInnerHTML渲染“markdown 输出”。修复关闭 raw HTML 直通渲染前用久经验证的净化器如 DOMPurify净化输出。仓库印证DeepCode 桌面端在 MarkdownContent.tsx 中使用react-markdown渲染 AI 会话中的 Markdown 内容并显式设置skipHtml跳过原始 HTML外部链接统一渲染为携带relnoreferrer noopener的组件——这正是本规则“关闭 raw HTML 直通 受控链接”的正面实践。REACT-TT-001在可行处用 Trusted Types配合 CSP加固 DOM XSS 写入点严重级别Low必需应当先以report-only模式启用 Trusted Types处理完违例后再强制启用应当集中管理 Trusted Types 策略并视为高风险代码不得创建简单“直通”不可信字符串的宽松策略。不安全模式HTML 写入点策略未净化就原样返回字符串代码库中散落大量策略难以审计。检测提示搜索trustedTypes.createPolicyCSP 指令require-trusted-types-for、trusted-types继续排查遗留 DOM 写入点REACT-DOM-001。修复实现少量严格限定的策略——HTML 策略使用净化器DOMPurify 或等价物Script URL 策略使用严格白名单先 report-only 修复违例再强制执行。依据MDN 与 W3C Trusted Types 规范都将其定位为通过受审查策略产出的类型化值锁定注入写入点、降低 DOM XSS 风险。4.3 URL 与跳转安全REACT-URL-001校验并约束用于href、src、导航与重定向的不可信 URL严重级别High仅当你能证明它们可被攻击者控制时必需任何源自不可信输入的 URL 都必须视为危险必须对 scheme 与适用时host 做白名单——通常只允许https:本地/开发可含http:以及应用内导航的相对 URL必须显式阻止javascript:与危险的data:用法除非有专门校验与明确用例应当优先使用同站相对路径如/settings而非绝对 URL必须校验returnTo/next/redirect参数见 REACT-REDIRECT-001。不安全模式img src{userProvidedUrl}可被用于跟踪/数据外泄用于脚本/iframe 更危险window.location nextnavigate(next)且next来自未经校验的查询参数。检测提示搜索href{、src{、window.location、location.href、window.open、navigate(、redirectTo、returnTo、next追溯值是否派生自 URL/查询/存储/API。修复实现共享safeUrl()工具——用new URL(value, base)解析强制 scheme 白名单与 host 白名单或强制同源重定向只允许以/开头的相对路径或严格白名单内的绝对源校验失败时回退到安全默认值。依据OWASP 指出 React 无法在不做专门校验的情况下安全处理javascript:或data:URL。REACT-REDIRECT-001防止开放重定向与不可信导航严重级别Medium必需必须校验源自不可信输入的跳转/导航目标next、returnTo、redirect只允许同站相对路径或对绝对 URL 使用严格可信源白名单。不安全模式window.location.href new URLSearchParams(location.search).get(next)navigate(next)且next来自查询参数。检测提示搜索next、returnTo、redirect、window.location、navigate(追溯跳转目标来源。修复只允许相对路径/^\/[^\s]*$/或白名单源非法时回退到安全默认值如/。说明开放重定向常被用于钓鱼并可能破坏 SSO/OAuth 流程。4.4 浏览器策略与第三方资源REACT-CSP-001部署并维护 CSP 作为纵深防御尤其渲染不可信内容时严重级别Medium 到 High必需生产环境应当部署 CSP渲染不可信内容或集成第三方脚本的应用必须部署应当尽量避免unsafe-inline与unsafe-eval需要内联脚本时应当使用 nonce/hash 并保持策略现实可维护应当用 CSP 要求/鼓励 SRI。不安全模式SPA 入口 HTML 完全没有 CSP大范围无理由依赖unsafe-inline/unsafe-evalscript-src *或过宽的源。检测提示查找服务端/CDN 配置、index.html响应头或框架配置中的 CSP仓库中不可见时标注“请在边缘层验证”。修复优先通过 HTTP 响应头下发 CSP先 report-only 减少破坏再强制执行。依据OWASP 将 CSP 描述为针对 XSS 的“纵深防御”即使在静态站上也有助于强制 SRI但不应作为唯一防线。REACT-SRI-001第三方脚本与样式必须使用 SRI或自托管严重级别Low必需第三方 JS 必须视为在你的源内执行任意代码从 CDN/第三方加载时应当使用 SRIintegrity...与适用的crossorigin应当固定精确版本避免latestURL关键代码应当优先自托管。不安全模式script srchttps://cdn.example.com/lib/latest.js/script无完整性校验无治理地由标签管理器动态加载任意脚本。检测提示在public/index.html、模板或 SSR 包装中搜索script src、link relstylesheet href、标签管理器片段识别运行时 JS 中动态加载的脚本。修复为稳定的第三方资源添加 SRI hash 或自托管对标签管理器实施治理见 REACT-3P-001。依据MDN 将 SRI 描述为让浏览器通过校验加密哈希确认 CDN 资源未被篡改的安全特性。REACT-3P-001第三方 JS 与标签管理器必须最小化并受治理严重级别High必需必须最小化第三方脚本把每个都当作供应链风险必须确切知道在你的源内执行了哪些第三方 JS、为什么执行应当实施治理审查并固定版本或内部镜像、通过数据层方式限制数据访问、使用 SRI 与 CSP、在可行处把不可信 UI 沙箱进 iframe。不安全模式未审查的分析/广告脚本以完整权限访问 DOM、Cookie、存储与用户数据可由非工程角色在无变更控制下改动的标签管理器。检测提示在 HTML/JS 中搜索常见厂商片段GTM、Segment、Hotjar、FullStory 等查找动态脚本插入document.createElement(script)、.src ...、.appendChild(script)。修复只保留必要的厂商可行处自托管或镜像脚本、使用 SRI、通过受控数据层限制数据暴露。依据OWASP 指出第三方 JS 服务器被攻破可注入恶意 JS带来任意代码执行与敏感信息泄露风险。REACT-HEADERS-001为 React 应用壳设置关键安全响应头应用内或边缘层严重级别Medium必需典型同源托管的 SPA应当设置 CSPContent-Security-Policy、X-Content-Type-Options: nosniff、防点击劫持CSPframe-ancestors和/或X-Frame-Options、Referrer-Policy、按需Permissions-Policy必须确保这些在某处CDN/边缘/服务器被设置即使不在仓库内。不安全模式任何地方应用或边缘都没有安全响应头渲染不可信内容或使用第三方脚本的应用缺失 CSP。检测提示检查仓库中的服务端/CDN 配置nginx、Cloudflare、Vercel 配置等缺失时标注“请在运行时/边缘层验证”。修复在边缘层集中设置响应头保持 CSP 现实可行并迭代演进report-only → enforce。依据MDN 点击劫持指南与 OWASP CSP 指南均推荐通过响应头交付并将其作为首选机制。4.5 认证、会话与授权REACT-AUTH-001令牌与会话处理必须对 XSS 有韧性避免在 Web Storage 存敏感数据严重级别Medium必需应当避免把会话标识符或长效令牌存入localStorage通常也包括 Web Storage 整体因为一次 XSS 即可将它们外泄若令牌必须存在客户端应当优先内存存储 短生命周期 刷新机制并必须限制作用域与轮换令牌避免长效 bearer 令牌进入持久存储可能时应优先用HTTPOnly Cookie存放会话令牌需配套 CSRF 策略见 REACT-CSRF-001。不安全模式localStorage.setItem(token, ...)/sessionStorage.setItem(token, ...)存认证令牌把 refresh token 持久化在localStorage把 Web Storage 数据当作可信数据。检测提示greplocalStorage.、sessionStorage.、setItem(、getItem(、token、jwt、refresh在认证代码中找“记住我”持久化令牌的写法。修复迁移到 HTTPOnly Cookie服务端改动 CSRF 防护或使用短生命周期内存令牌降低令牌作用域与生命周期。依据OWASP HTML5 指南建议避免在本地存储中保存敏感信息与会话标识符并警告单次 XSS 即可窃取 Web Storage 中的全部数据OAuth 浏览器应用草案也讨论了 localStorage 中的令牌可被恶意 JS如经 XSS访问。REACT-CSRF-001Cookie 认证的状态变更请求必须受 CSRF 防护严重级别High注意如果应用不使用基于 Cookie 的认证例如使用 Authorization 头则不存在 CSRF 问题。必需若应用依赖 Cookie 认证必须为状态变更请求POST/PUT/PATCH/DELETE提供 CSRF 防护应当采用 CSRF 令牌机制synchronizer token 或 double-submit cookie或其他与后端匹配的稳健模式应当使用 SameSite Cookie 作为纵深防御而非唯一防线。不安全模式fetch(/api/transfer, { method: POST, credentials: include })且无 CSRF 令牌/头、仅依赖 Cookie用 GET 执行状态变更。检测提示枚举状态变更网络调用并检查是否使用credentials: include或withCredentials: true是否携带 CSRF 令牌头如X-CSRF-Token搜索 “csrf” 工具缺失则视为可疑。修复添加 CSRF 令牌流程——从安全端点获取令牌并附加到状态变更请求、服务端校验保留 SameSite Cookie 与 Origin/Referer 校验作为纵深防御。依据OWASP CSRF 指南解释了 SameSiteLax/Strict/None作为纵深防御技术的行为以及 Lax 常是可用性与安全性的平衡点但不能完全替代 CSRF 防护。REACT-AUTHZ-001不要依赖纯前端授权严重级别High仅当作为主要防护时必需必须把所有前端授权检查视为仅用于 UX任何受保护资源或操作的授权都必须在服务端强制执行。不安全模式UI 中“隐藏”的受保护操作但 API 无服务端检查即可被调用客户端检查如if (user.isAdmin) { showAdminPanel(); }而无服务端强制。检测提示检查敏感操作周围的 UI 门控并验证服务端端点是否强制执行授权纯前端审计中应报告为“客户端检查不是安全措施请验证后端”。修复添加/确认服务端授权检查前端门控仅作为便利。说明这是通用 Web 应用安全属性——React 本身无法保护服务端资源。4.6 网络与数据外泄REACT-NET-001防止经动态出站请求造成数据外泄与凭据泄露严重级别Medium 到 High必需必须避免向攻击者控制的源发起携带认证的请求应当避免让用户输入控制请求目标scheme/host/port应当集中封装网络客户端fetch/axios并统一固定baseURL或严格白名单、严格处理重定向、显式使用credentials。不安全模式fetch(userProvidedUrl, { credentials: include })axios.create({ baseURL: userProvidedBase })客户端“URL 抓取/预览”功能携带敏感头访问任意域名。检测提示搜索fetch(/axios(中第一个参数或baseURL派生自查询参数、localStorage、API 响应、postMessage 的情况搜索credentials: include、withCredentials: true。修复强制目标白名单除非明确需要否则禁止跨源请求对任何非白名单目标剥离凭据/Authorization 头。说明即使浏览器限制了部分跨源行为向不可信端点泄露令牌/头仍是常见失败模式。4.7 跨窗口消息与文件REACT-POSTMSG-001postMessage必须校验源并把载荷视为不可信数据严重级别Medium 到 High取决于消息能触发什么必需发送消息时必须指定精确的targetOrigin而非*除非有严格理由接收时必须校验event.origin并校验消息结构绝不把消息数据当代码执行或作为 HTML 插入 DOM。不安全模式向未知目标window.postMessage(data, *)接收侧window.addEventListener(message, (e) { eval(e.data) })或element.innerHTML e.data。检测提示搜索postMessage(、addEventListener(message检查是否存在源校验与安全处理。修复添加严格源白名单与结构校验如用 zod把消息载荷严格当数据处理经 React 安全渲染。依据OWASP HTML5 指南建议为postMessage指定期望源、检查发送方源、校验数据、避免对消息内容使用 eval/innerHTML。REACT-FILE-001文件上传与预览不得制造客户端活动内容漏洞严重级别Medium可能导致存储型 XSS 时为 High必需必须把用户上传文件与预览视为潜在恶意不得未经净化且非明确需求时内联渲染上传的 HTML/SVG 等活动内容客户端文件类型校验只服务于 UX安全必须依赖服务端校验。不安全模式把用户上传的 HTML 当内容渲染未经净化通过dangerouslySetInnerHTML或iframe srcdoc...内联渲染不可信 SVG/HTML。检测提示搜索上传组件与预览逻辑input typefile、FileReader、URL.createObjectURL、iframe、object、embed追溯上传内容后续在何处被展示。修复限制接受类型、按需净化、对风险类型优先走下载/附件流程确保服务端执行真实策略类型检查、重命名、扫描、存储在 webroot 之外。依据OWASP 文件上传指南强调扩展名白名单、类型校验、文件名生成、大小限制、webroot 外存储并提示文件可公开获取时要考虑“客户端活动内容XSS、CSRF 等”风险。4.8 Service WorkerREACT-SW-001Service Worker 是高权限组件要求 HTTPS 与安全的缓存/更新规则严重级别Medium必需Service Worker 必须通过 HTTPS 提供localhost开发除外且只能在安全上下文中部署必须避免缓存敏感的认证 API 响应除非经过显式设计与威胁建模应当实现安全更新策略提示重载、版本化缓存、activate 时清理旧缓存。不安全模式为认证应用注册 Service Worker 并无差别缓存“一切”缓存中包含跨账号共享的 PII 或用户专属内容的长效缓存。检测提示搜索navigator.serviceWorker.register、workbox、precacheAndRoute、自定义fetch处理器检查缓存模式caches.open、cache.put、respondWith。修复把缓存限制在静态资源JS/CSS/图片除非有设计好的离线模型必须缓存用户数据时确保缓存键按用户隔离提供清晰的更新机制。依据MDN 指出 Service Worker 出于安全原因要求 HTTPS并像代理一样处理请求/响应“安全上下文”机制正是为了防止 MITM 攻击者访问强大 API。4.9 供应链与依赖REACT-SUPPLY-001依赖与供应链卫生前端 构建工具严重级别Low必需必须使用 lockfile 并在 CI 中强制可复现安装应当定期审计依赖并对以下对象的安全通告快速响应React、react-dom、路由库、构建工具Vite/Webpack、净化器、认证库等应当降低安装期脚本攻击与 typosquatting 风险。审计重点CI 应使用npm ci或 Yarn frozen lockfile / pnpm 等价物防止漂移使用漏洞扫描npm audit、Dependabot/告警等。不安全模式无 lockfile 或 CI 忽略 lockfileCI 用npm install导致不可复现构建未固定或未审查的高风险依赖、未经审查的突然大版本升级盲目运行第三方包的安装脚本。检测提示检查 lockfilepackage-lock.json、yarn.lock、pnpm-lock.yaml检查 CI 脚本用npm install还是npm ci搜索postinstall脚本与可疑构建步骤。修复使用 lockfile 并在 CI 强制如npm ci定期审计并负责任地固定/升级可行处限制安装脚本。依据npm 文档把npm audit描述为向 registry 提交依赖树以获取已知漏洞报告并可选择性通过npm audit fix修复部分漏洞仍需人工审查npm ci面向自动化/CI 环境要求已有 lockfile且package.json与 lockfile 不一致时直接失败OWASP NPM 指南明确要求强制 lockfile 与npm ci/yarn install --frozen-lockfile并指出安装期脚本风险与--ignore-scripts的缓解价值。仓库印证DeepCode 桌面端 desktop/package.json 带有package-lock.json可复现安装、npm ci友好的 CI 脚本结构并提供了audit:licenses脚本scripts/audit-licenses.py用于许可证/依赖审计同时通过overrides固定了nanoid版本——体现了“锁定依赖、控制供应链”的工程实践。5. 实战扫描启发如何“狩猎”漏洞§5主动扫描时规范给出了高信号检索模式清单可直接用于 grep 式代码搜索Raw HTML / XSS 逃生舱dangerouslySetInnerHTML、__html:markdown HTML 直通标志rehype-raw、allowDangerousHtml、sanitize: false。DOM XSS 写入点innerHTML、outerHTML、insertAdjacentHTML、document.write、DOMParser、createContextualFragment。危险 JS 执行eval(、new Function(、setTimeout(、setInterval(。不可信 URL 注入 / 导航值为不可信的href{/src{window.location、location.href、window.open、navigate(查询参数next、returnTo、redirect。令牌/会话风险localStorage.setItem、sessionStorage.setItem、getItem(配合token、jwt、refresh。Cookie/CSRF 耦合状态变更请求上的credentials: include、withCredentials: true但无 CSRF 头。第三方脚本public/index.html中的script src...标签管理器片段与动态脚本插入。Service Workernavigator.serviceWorker.register、Workbox 使用、自定义fetch处理器。postMessagepostMessage(用*缺少event.origin校验。供应链缺少 lockfile、CI 用npm install、无审计步骤、可疑的 postinstall 脚本。扫描后必须尽量确认三件事数据来源不可信 vs 可信、写入点类型React 逃生舱 vs DOM 写入点 vs 导航 vs 存储、存在的防护措施净化、白名单、CSP/Trusted Types、CSRF 令牌、响应头、治理。6. 规则在真实项目中的落地DeepCode 桌面端实践本文主角规范并非纸上谈兵——DeepCode 桌面端是 React 19 TypeScript 5 Vite 的真实代码库多处实践与本规范一一对应REACT-MARKUP-001Markdown 安全渲染MarkdownContent.tsx 渲染 AI 会话消息时使用react-markdown并显式skipHtml默认不渲染原始 HTML代码块通过prism-react-renderer以 token 形式渲染而非 HTML 字符串这正是“关闭 raw HTML 直通 结构化渲染”的规范写法。REACT-AUTH-001Web Storage 使用节制桌面端确实在localStorage中持久化状态但均为非敏感 UI 状态——如主题外观appearance.ts 中的deepcode.desktop.appearance.v1、语言偏好i18n.ts、当前工作区/线程选择useWorkspaceController.ts未出现把认证令牌写入 Web Storage 的模式。规范允许对非敏感状态使用存储但要校验/转义后再使用。REACT-URL-001 / 链接导航安全外部链接统一使用target_blank并携带relnoreferrer noopener如 McpPage.tsx 与 MarkdownContent 中的ExternalLink组件避免新窗口反向利用window.opener符合链接安全的纵深防御要求。REACT-SUPPLY-001依赖锁定与审计desktop/package.json 的构建链包含check:version、check:tauri、check:protocol与tsc --noEmit门禁并提供audit:licenses依赖审计脚本与package-lock.json通过overrides显式固定nanoid版本。这与“lockfile 审计 固定版本”的供应链要求一致。CSP 与响应头REACT-CSP-001 / REACT-HEADERS-001桌面端是 Tauri 应用src-tauri/安全上下文由桌面 WebView 与 capabilities/main.json 的能力声明约束规范中“CSP 可能在边缘层/宿主层设置而非仓库内”的判断逻辑在此类打包型应用中尤其适用——扫描时若在仓库内不可见应报告为“请在运行时/宿主配置验证”。将这些实践与规范对照可以清晰地看到“安全默认”不是一句口号而是可以通过“渲染层关掉危险特性、存储层不碰敏感数据、网络层固定目标、供应链层锁定依赖”逐条落地。7. 使用这份规范的完整工作流结合 SKILL.md 与本文规范推荐的工作流如下识别技术栈先确定项目中的语言与框架本规范对应 React 19.x TypeScript 5.x 前端后端另有 FastAPI/Flask/Django/Express 等独立参考文档。加载匹配文档从 references/ 加载所有与当前框架相关的参考文档前后端并存的项目要同时加载前后端文档。选择模式写新代码 → 生成模式逐条遵循 MUST/SHOULD改既有代码 → 被动审查模式顺带指出附近违例用户要求扫描 → 主动审计模式按 §5 的顺序与检索清单系统性搜索并按 §2.3 结构化格式输出。产出报告报告以 markdown 文件落盘如security_best_practices_report.md顶部附执行摘要按严重级别分节为关键发现附带一句话影响陈述并确保引用代码时包含行号。修复单次修复一个发现注释中注明所依据的规则与不这样做的危险性修复前评估对现有功能的影响、避免引入回归遵循项目既有的变更/提交与测试流程避免把不相关发现打包进同一个提交。8. 总结DeepCode 内置的这份 React (JavaScript/TypeScript) 前端安全规范用“规范性要求MUST/SHOULD/MAY 审计规则REACT-* 编号体系”的形式把 React 19 前端的安全要点变成了可生成、可审查、可取证的工程化约束从密钥不进 bundleREACT-CONFIG-001、XSS 逃生舱管控REACT-XSS-001/002、REACT-DOM-001、REACT-MARKUP-001、REACT-TT-001、URL/重定向校验REACT-URL-001、REACT-REDIRECT-001到 CSP/SRI/第三方脚本治理REACT-CSP-001、REACT-SRI-001、REACT-3P-001、REACT-HEADERS-001、令牌与 CSRFREACT-AUTH-001、REACT-CSRF-001、REACT-AUTHZ-001、网络外泄防护REACT-NET-001、消息与文件REACT-POSTMSG-001、REACT-FILE-001、Service WorkerREACT-SW-001与供应链卫生REACT-SUPPLY-001。对开发者而言这份规范的价值在于它既是一份可直接照做的安全编码清单每条规则都有“不安全模式 → 检测提示 → 修复”的完整闭环又是一套可嵌入 Agent 工作流的可执行审计协议。配合 DeepCode 桌面端自身的落地案例你可以把它作为团队前端安全基线或作为 AI 编码助手生成与审查 React 代码时的安全准绳。【免费下载链接】DeepCodeDeepCode: Open Agentic Coding (Agent Harness Loop Engineering Multi-Agent Orchestration)项目地址: https://gitcode.com/GitHub_Trending/deepc/DeepCode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考