同一源多用户资源场景下，具有全局副作用的HTTP响应头咨询

Great question—balancing user customization with multi-tenant security is tricky, and you’ve already flagged some of the most high-risk headers. Beyond the ones you listed (Alt-Svc, Public-Key-Pins, Server, Set-Cookie, Strict-Transport-Security), here are additional headers that can impact the entire origin or other users’ resources:

• Content-Security-Policy (CSP) & Content-Security-Policy-Report-Only:
  While CSP can be scoped to specific paths, users might inadvertently (or intentionally) set origin-wide directives (e.g., default-src 'self' without a path restriction). This would block all resources on the origin that don’t comply with the policy—including other users’ scripts, styles, or media. The report-only variant also risks leaking sensitive cross-user error data to the user’s specified report endpoint.

• Permissions-Policy:
  This header controls access to browser features like camera, geolocation, or JavaScript APIs. A user-set policy that applies to the entire origin (e.g., geolocation=()) would restrict feature access for all pages under the domain, breaking functionality for other tenants who rely on those features.

• Cross-Origin-Embedder-Policy (COEP) & Cross-Origin-Opener-Policy (COOP):
  These headers enforce cross-origin isolation to enable powerful features like SharedArrayBuffer. Once a resource sets either header (especially with values like require-corp or same-origin), browsers isolate the entire origin’s browsing context. Other users’ resources that don’t align with this isolation model may fail to load, or lose access to cross-origin resources they depend on.

• Clear-Site-Data:
  This header can clear all browser storage tied to the origin—including cookies, localStorage, sessionStorage, and cached data. A malicious or careless user could wipe out all other tenants’ stored data, leading to widespread data loss and broken user sessions.

• Referrer-Policy:
  Though often thought of as resource-specific, browsers may apply an origin-wide referrer policy if it’s set by a top-level resource. For example, a user setting referrer-policy: no-referrer would prevent all resources on the origin from sending referrer data, which could break functionality for other tenants who rely on referrer information for analytics or access control.

• Expect-CT:
  This header enforces Certificate Transparency (CT) requirements for HTTPS connections. Setting it on a resource applies the CT policy to the entire origin for subsequent requests, potentially blocking access to other users’ resources if their certificates don’t meet the specified CT criteria.

• NEL (Network Error Logging) & Report-To:
  These headers configure endpoints for collecting network error reports. If a user sets these, browsers will send error reports for all network requests under the origin—including those from other tenants—to the user’s specified endpoint. This leaks sensitive information about other users’ traffic and resource failures.

Additional Mitigation Tips #

Even headers that seem resource-specific can become dangerous if users set them without proper path scoping. For example, Cache-Control with a long max-age might not affect the origin directly, but a user setting Cache-Control: public, max-age=31536000 on a shared resource could lead to stale content being served to all users. To mitigate this, you might want to:

1. Restrict users to only setting headers explicitly safe for resource-level customization (like Access-Control-Allow-Origin, Content-Type, Cache-Control with path-aware directives).
2. Automatically prefix any user-set header directives with their directory path to prevent origin-wide impact.
3. Validate and sanitize all user-provided headers to block high-risk ones entirely.

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