Chrome扩展Manifest V3为fetch请求设置Referer头规则不生效

规则不生效是配置错误导致的，核心问题有两个：

• resourceTypes匹配范围错误：当前仅配置main_frame，该类型只匹配顶层标签页的导航跳转请求，fetch、XMLHttpRequest发起的异步请求，在declarativeNetRequest的规则体系中对应的资源类型是xmlhttprequest，完全不在现有规则的匹配范围内。
• 规则匹配逻辑和头值不符合业务要求：
  1. 现有urlFilter为https://api.myserver.com，仅匹配域名根路径，所有子路径的API请求都不会命中规则；
  2. 你设置的Referer值为whatever，Django的CSRF校验逻辑会验证Referer的源是否在CSRF_TRUSTED_ORIGINS信任列表内，非法值即使被带上也会被拦截。

额外注意：Referer属于浏览器的禁止修改头（Forbidden header name），直接在fetch的headers参数里手动设置Referer会被浏览器自动丢弃，只能通过declarativeNetRequest这类扩展API修改。

1. 补全manifest.json权限 #

必须声明目标API域名的host权限，否则declarativeNetRequest无权修改对应域名的请求头：

// 仅展示需要调整的配置段，其余原有配置保留
{
  "permissions": [
    // 原有其他权限保留
    "declarativeNetRequestWithHostAccess",
    "declarativeNetRequestFeedback"
  ],
  "host_permissions": [
    "https://api.myserver.com/*" // 新增，声明目标API域名的操作权限
  ],
  "declarative_net_request": {
    "rule_resources": [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules.json"
    }]
  }
}

2. 修正rules.json规则 #

调整匹配范围，设置合法的Referer值：

[
  {
    "id": 1,
    "priority": 1,
    "action": {
      "type": "modifyHeaders",
      "requestHeaders": [
        {
          "header": "Referer",
          "operation": "set",
          "value": "https://api.myserver.com/" // 替换为你Django配置中CSRF_TRUSTED_ORIGINS包含的源地址
        }
      ]
    },
    "condition": {
      "urlFilter": "https://api.myserver.com/*", // 增加通配符匹配所有子路径请求
      "resourceTypes": [
        "main_frame", // 保留原有页面导航的匹配逻辑
        "xmlhttprequest" // 新增，匹配fetch/XHR类异步请求
      ]
    }
  }
]

1. 打开chrome://extensions页面，找到对应扩展点击重新加载，确保新配置和规则生效；
2. 触发post_data函数发起请求，打开扩展的Service Worker控制台，查看onRuleMatchedDebug回调是否输出匹配日志；
3. 在浏览器网络面板检查对应POST请求的请求头，确认已携带正确的Referer值，接口不再返回403 CSRF错误。

补充：如果需要覆盖popup页面、扩展页等其他扩展上下文发起的请求，可以按需在resourceTypes中添加other、script等对应资源类型。

内容的提问来源于stack exchange，提问作者somejonus