Skip to content

Proxy Header and Cookie Handling

The HTTP proxy sanitizes every response from a remote QIE before writing it back to the browser. A compromised remote QIE could in principle return arbitrary response headers, so the proxy strips browser security headers, forwards only an allowlist of headers, and rescopes the site's cookies.

Stripped response headers

These are dropped unconditionally. A remote QIE cannot influence browser security headers for the Hub origin:

Header Reason
Strict-Transport-Security Could pin the operator's browser to an attacker-chosen TLS configuration
Content-Security-Policy Could relax CSP for the per-site subdomain in attacker-chosen ways
Content-Security-Policy-Report-Only Same
X-Frame-Options Could change clickjacking protection
Public-Key-Pins Could pin the browser to an attacker's keys
Public-Key-Pins-Report-Only Same

Forwardable response headers (allowlist)

Only these headers are forwarded from a remote QIE response to the browser:

content-type, content-encoding, content-disposition,
content-language, cache-control, expires, etag, last-modified, vary,
pragma, set-cookie, location, x-gwt-permutation,
x-content-type-options, x-requested-with, accept-ranges,
content-range, allow, retry-after

Anything not in this list is silently dropped. (Content-Length is deliberately not forwarded from the remote response. The servlet container sets/chunks it from the bytes actually streamed, so a mismatched declared length from a compromised site cannot truncate or mis-frame the response.) New headers required by new QIE features must be added to the allowlist explicitly.

Set-Cookie headers are forwarded with these adjustments:

  • The cookie's Domain attribute is dropped. A remote QIE cannot set cookies that span across other subdomains of the Hub.
  • A cookie with no Path attribute gets Path=/.
  • In subdomain routing the Secure flag is always added.
  • In path-based routing the site's session cookie is renamed to <name>__<label> and its Path is replaced with /sites/<label>, so it cannot overwrite the Hub's own session cookie on the shared hostname and the browser sends it only with that site's requests. The proxy restores the original name before passing the cookie to the site.

This keeps each site's session cookies scoped to its own subdomain even when the remote QIE issues a cookie with a domain-wide scope.