硬编码域名或api地址需全局搜索https?://、"api"、"key"、"dev"等敏感字符串，覆盖js/html/css/注释及dist产物；重点排查fetch、script src、meta标签和sdk初始化代码，并通过构建时替换和ci自动化扫描拦截。
硬编码域名或API地址怎么找
硬编码漏洞不是运行时错误，而是代码里直接写死的敏感字符串——比如 https://api-prod.example.com、http://localhost:8080、dev-key-12345 这类值。它们出现在前端 JS、HTML 的 script 标签、fetch 调用、src 属性、注释甚至 CSS 里。排查第一步就是全局搜索这些“一眼假”的字符串。
建议用编辑器或命令行执行以下搜索（注意大小写和引号变体）：
-
https?://（匹配所有协议开头的 URL） -
"api"、'api'、api\w*（带 api 关键字的字符串） -
"key"、"token"、"secret"、"dev"、"test"（常见环境标识） -
// TODO、// FIXME（注释里常藏调试用硬编码）
特别注意构建工具生成的产物（如 dist/ 目录），有时开发环境配置被意外打包进生产 JS 文件中。
为什么 fetch 和 XMLHttpRequest 是重灾区
前端发请求时，如果直接在 fetch('https://staging-api.company.com/v1/users') 里写死地址，就等于把部署环境耦合进了代码。一旦上线，要么改代码重新打包，要么请求失败；更糟的是，测试环境地址可能暴露内部结构（如 http://10.0.1.5:3000）或凭证（如 ?key=abc123）。
常见踩坑点：
- 多个
fetch调用分散在不同组件里，各自维护一套 base URL - 使用
process.env.NODE_ENV === 'development'切换地址，但未对生产环境做兜底校验 - URL 拼接时用字符串模板：
`${API_BASE}/user/${id}`，而API_BASE本身是硬编码变量 - 第三方 SDK 初始化时传入硬编码 endpoint（如 Sentry、Plausible 的配置）
这类问题不会报错，但会让环境切换不可控、审计难追溯、安全扫描工具容易标红。
HTML 中的硬编码怎么漏掉又怎么补救
很多人只查 JS，却忽略 HTML 本身。比如：
<img src="https://cdn-dev.example.com/logo.png?x-oss-process=image/resize,p_40">-
<script src="https://unpkg.com/react@18/umd/react.development.js"></script>（开发版 CDN 地址混入生产页） -
<meta name="api-url" content="http://localhost:8000">（通过 meta 注入，但没清理） - 注释里残留：
<!-- TODO: replace with https://prod-api... -->
修复不能只靠“删注释”。关键是建立注入机制：用构建时替换（如 Webpack 的 DefinePlugin 或 Vite 的 import.meta.env），或由后端渲染时注入统一配置对象到 window.APP_CONFIG。避免让前端自己“猜”该连谁。
CI/CD 流程里怎么卡住硬编码提交
人工审查会漏，必须自动化拦截。在 Git 提交前或 CI 流程中加入检查：
- 用
grep -r "https\?://" src/ | grep -v "github.com\|unpkg.com\|jsdelivr.net"快速过滤可疑 URL - 用
truffleHog或gitleaks扫描 commit 历史，识别密钥类硬编码 - 在 ESLint 中加自定义规则，禁止
fetch第一个参数为字符串字面量（强制走配置变量） - 对 HTML 使用
html-validate配合自定义规则，校验src、href属性是否匹配白名单正则
最易被忽略的一点：构建产物（dist/）也要纳入扫描范围。很多团队只扫 src/，结果发现生产包里还躺着 http://127.0.0.1:9000 —— 因为构建脚本把本地配置打进了 bundle。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
