In index.js the corsHeaders() function (lines ~19-21) computes allowOrigin as: configuredOrigin === '*' ? '*' : (requestOrigin === configuredOrigin ? requestOrigin : configuredOrigin). When the request's Origin does not match the configured value, the response still echoes back configuredOrigin as access-control-allow-origin instead of refusing or omitting the header. Browsers will block the cross-origin request correctly (because the value doesn't match the actual request origin), but the configured origin string is unnecessarily disclosed to any caller. The correct behaviour is to either omit the ACAO header entirely or return a fixed sentinel (e.g. null) when the origins don't match, which is the standard pattern used by proxies and reverse-proxies. This matters whenever OPENCODE_LLM_PROXY_TOKEN is set but the CORS origin whitelist is also configured, because an attacker can probe the header to discover the expected origin value.
In
index.jsthecorsHeaders()function (lines ~19-21) computesallowOriginas:configuredOrigin === '*' ? '*' : (requestOrigin === configuredOrigin ? requestOrigin : configuredOrigin). When the request'sOrigindoes not match the configured value, the response still echoes backconfiguredOriginasaccess-control-allow-origininstead of refusing or omitting the header. Browsers will block the cross-origin request correctly (because the value doesn't match the actual request origin), but the configured origin string is unnecessarily disclosed to any caller. The correct behaviour is to either omit the ACAO header entirely or return a fixed sentinel (e.g.null) when the origins don't match, which is the standard pattern used by proxies and reverse-proxies. This matters wheneverOPENCODE_LLM_PROXY_TOKENis set but the CORS origin whitelist is also configured, because an attacker can probe the header to discover the expected origin value.