How Timing-Allow-Origin Controls Resource Timing

The Timing-Allow-Origin (TAO) HTTP response header determines whether a web page has permission to access detailed, low-level network performance metrics for third-party resources via the Resource Timing API. Without this header, browsers restrict cross-origin assets to basic, coarse-grained duration metrics to prevent side-channel security risks, such as inferring a user's browsing state or authentication status. By explicitly serving Timing-Allow-Origin, resource servers grant consuming domains visibility into sensitive performance phases, including DNS lookup, TCP handshake, TLS negotiation, and Time to First Byte (TTFB).

The Security Restriction: Why Metrics Are Blocked

The browser's Resource Timing API (window.performance.getEntriesByType('resource')) logs timestamps for network requests made by an application. When an asset (such as an image, script, stylesheet, or API response) is hosted on a different origin, sharing detailed timing information introduces cross-origin side-channel vulnerabilities.

Attackers could use sub-millisecond network measurements to detect whether a user is logged into an external service, determine if a resource is cached, or infer user-specific content sizes. To prevent these timing attacks, modern browsers enforce privacy boundaries. By default, cross-origin requests restrict access to the following granular timing properties, zeroing them out:

  • redirectStart and redirectEnd
  • domainLookupStart and domainLookupEnd
  • connectStart and connectEnd
  • secureConnectionStart
  • requestStart
  • responseStart

Only high-level values—such as startTime, responseEnd, and total duration—are made available to the parent document without explicit permission.

How Timing-Allow-Origin Restores Access

The Timing-Allow-Origin response header acts as an opt-in mechanism provided by the resource host. When a browser detects this header in an HTTP response, it compares the current document's origin against the header's value. If the origin is permitted, the browser populates all low-level Resource Timing metrics instead of zeroing them out.

This enables Real User Monitoring (RUM) agents, performance tools, and developers to pinpoint exact network bottlenecks occurring during third-party asset retrieval.

Header Syntax and Values

The resource server must deliver the header with the HTTP response using one of the following directives:

  1. Wildcard Access (*):

    Timing-Allow-Origin: *

    This permits any origin loading the resource to access its full network breakdown. This is the standard configuration for public assets, open-source libraries, and content delivery networks (CDNs).

  2. Specific Origin:

    Timing-Allow-Origin: https://example.com

    This restricts access to a single designated origin, ensuring that unauthorized third-party sites embedding the resource cannot view detailed timings.

  3. Multiple Origins:

    Timing-Allow-Origin: https://example.com, https://sub.example.com

    Some implementations support a comma-delimited list of origins, though generating the header dynamically to mirror an approved Origin request header is often the more reliable approach.

Implementation Considerations

  • Not the Same as CORS: The Timing-Allow-Origin header is distinct from Access-Control-Allow-Origin. CORS controls access to the resource data itself (the response body), whereas TAO controls access to the underlying network transport metrics. A resource can allow timing inspection via TAO without allowing its content to be read by JavaScript via CORS.
  • CDNs and Static Assets: Public assets like fonts, icons, and static images should typically be configured to serve Timing-Allow-Origin: * at the CDN level to ensure frontend observability tools can detect network anomalies.
  • Sensitive Endpoints: The header should be avoided on private, authenticated, or user-specific endpoints where subtle differences in server processing time could leak information about the user or session.