Release: 2026 release (Personal Developer Instance).
Setup: OAuth (implicit grant) works from a browser SPA at http://localhost:5173; I get a valid token. For the data call I created a CORS rule: REST API = Table API [now/table], Domain = http://localhost:5173, Methods = GET,POST, Access-Control-Allow-Headers = authorization,content-type. Rule is Active; single matching rule; system cache flushed
Problem: The preflight never returns authorization, so the browser blocks Authorization: Bearer calls.
Reproduction (server-side, no browser cache):
curl -i -X OPTIONS 'https://<instance>.service-now.com/api/now/table/sys_user?sysparm_limit=1' \
-H 'Origin: http://localhost:5173' \
-H 'Access-Control-Request-Method: GET' \
-H 'Access-Control-Request-Headers: authorization,content-type'
Returns:
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET,POST
Access-Control-Allow-Headers: content-type <-- "authorization" dropped
Control test: setting the rule's allowed headers to a custom value x-test-header and requesting it -> the preflight does return Access-Control-Allow-Headers: x-test-header. So the rule is correct and is the one responding; only authorization is stripped.
Questions: Is stripping Authorization from CORS allow-headers intended hardening in this release? If so, is there a supported property/config to allow it for a specific origin? If not, this looks like a regression (older releases returned authorization,content-type).
