Chrome扩展跨域请求需在manifest.json的host_permissions中显式声明目标域名（如"https://api.example.com/"），内容脚本须通过chrome.runtime.sendMessage委托service worker发起fetch，CORS头对扩展无拦截作用但影响数据传递给页面脚本。
在浏览器扩展中发送跨域请求，和普通网页不同：它不受同源策略的严格限制，但必须显式声明权限，且需兼顾安全性与沙箱隔离机制。关键不在于“绕过”跨域，而在于“合规使用扩展能力”。
扩展 manifest 中正确声明 host 权限
从 Manifest V3 开始，所有跨域请求必须在 manifest.json 的 host_permissions 字段中明确列出目标域名（支持通配符，但需谨慎）。
- ✅ 正确示例：
"host_permissions": ["https://api.example.com/", "https://*.googleapis.com/"] - ❌ 错误写法：
"*://*/*"（过于宽泛，Chrome 会拒绝安装或触发审核警告） - ⚠️ 注意：不能只写
"https://api.example.com"（缺少末尾斜杠），必须带协议+路径前缀（如/），否则权限不生效
使用 chrome.runtime.sendMessage 或 fetch 发送请求
扩展内容脚本（content script）默认运行在页面上下文中，但无法直接调用 fetch 访问未授权域名；而后台服务工作线程（service worker）或弹出页等可直接使用 fetch，前提是已声明对应 host 权限。
- 推荐在 service worker 或 popup.js 中发请求：它们拥有完整网络能力，且不共享页面 DOM，更安全
- 若需从 content script 触发，应通过
chrome.runtime.sendMessage将参数传给 service worker，由后者执行fetch并返回结果 - 避免在 content script 中硬编码敏感 token 或拼接用户可控 URL，防止被宿主页面污染或劫持
CORS 头在扩展场景中的实际作用
即使扩展有 host 权限，目标服务器仍可能返回 CORS 头——但这些头对扩展本身无约束力。浏览器不会因响应中缺失 Access-Control-Allow-Origin 而阻止扩展的请求。不过，CORS 头会影响两个细节：
- 如果扩展将响应数据传递给页面脚本（例如注入到 DOM），而页面脚本后续尝试读取该响应体，此时同源策略会重新介入，缺少 CORS 头会导致读取失败
- 某些 API（如
Response.arrayBuffer()）在跨域响应中若未带Access-Control-Expose-Headers，部分自定义 header 可能不可读 - 建议后端仍按标准设置
Access-Control-Allow-Origin（哪怕只为chrome-extension://[id]），便于调试和兼容未来变化
避免常见安全隐患
扩展权限高、影响面广，跨域请求环节容易成为攻击入口：
- 禁用
credentials: 'include'除非绝对必要；若需带 cookie，确保目标域名可信且不接受任意 origin 回调 - 不信任用户输入作为请求 URL 的一部分，防止 SSRF 或开放重定向；对动态域名做白名单校验（如只允许
api.github.com和api.gitlab.com） - 敏感请求（如修改账户、获取私有数据）建议增加扩展内二次确认或权限分级（例如单独申请“读取 GitHub 私有仓库”权限）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
