Interactive Brokers Client Portal Web API 所有POST请求均返回403错误

你遇到的“GET请求全部正常、所有POST请求全返403”的情况，没有代码层面的逻辑错误，完全是触发了IBKR Client Portal网关的三层前置校验规则，对应你贴的请求内容就能逐一对上：

• 缺失POST强制校验头X-Crumb：IBKR从v1.10版本开始，所有写操作（POST请求）必须携带这个专属令牌，GET类查询请求不需要，缺了这个头请求会在网关入口直接被拦下，返回403，根本走不到会话校验环节。
• 非法Origin拦截：你当前请求的Origin是Chrome扩展的内置地址chrome-extension://jnblchdcckkmedocgchlfmfhbaihjdnl，不在网关的跨域白名单范围内。网关默认只认可两个来源的请求：本地控制台页面自身的https://localhost:5000、同网络段的http://127.0.0.1:5000，其他来源的POST请求会被直接拦截返403。
• 之前参考的UA修改逻辑完全失效：Chrome从72版本开始，webRequest接口要修改浏览器内置的默认请求头（比如User-Agent），必须额外申请extraHeaders权限。你现在的代码没加这个参数，实际发出去的请求User-Agent根本没改成Console，还是Chrome扩展的默认UA，直接触发网关的非白名单客户端拦截。

• 补全X-Crumb请求头：正常打开本地网关控制台完成登录流程后，调用GET /v1/portal/iserver/auth/status 接口，从返回的JSON响应体里拿到crumb字段的值，给所有POST请求追加请求头：xhr.setRequestHeader('X-Crumb', '获取到的crumb值')。注意crumb值会跟随会话同步刷新，重新登录网关后值会变化，过期的crumb也会触发403，建议每次发核心操作请求前先拉一次最新的auth状态。
• 绕过Origin拦截：如果是在Chrome扩展场景下发请求，在webRequest的请求头修改逻辑里，把所有发往https://localhost:5000的请求的Origin头直接删除。网关检测不到非白名单Origin时，会默认把请求判定为同域控制台发起的，不会触发跨域拦截。
• 修复失效的UA修改逻辑：把webRequest监听器的第三个配置数组从['blocking', 'requestHeaders']改成['blocking', 'requestHeaders', 'extraHeaders']，确保User-Agent的修改能真正生效，不会被浏览器底层拦下来。
• 修正XHR的Cookie携带配置：发请求前一定要设置xhr.withCredentials = true，跨域请求下开启这个配置，浏览器才会自动携带网关种下的会话Cookie。不要手动在代码里拼接Cookie字符串塞请求头，这类属于浏览器受限的请求头，会被自动过滤，反而导致会话校验失败。

• 不要手动构造Cookie、Host这类受限请求头，这类头通过JS的setRequestHeader根本加不进去，你当前请求里看到的Cookie全是浏览器自动携带的，不是代码手动塞的。
• 靠修改User-Agent为Console绕开拦截的方法已经过时了，现在网关的校验优先级是：先检查是否有有效X-Crumb -> 再检查Origin是否在白名单 -> 最后校验客户端UA是否合法，前面两步不通过的话，UA改对了也会返403。
• 你调用的/v1/portal/iserver/account端点路径完全正确，没有接口错误，触发403全是前置拦截规则导致的，和你传的acctId值没有关系。

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