Timing-Allow-Origin

TL;DR: Specifies which origins can access detailed timing information for cross-origin resources via the Resource Timing API. Use for performance monitoring across domains.

What is Timing-Allow-Origin?

The Timing-Allow-Origin (TAO) header controls which origins can read detailed Resource Timing data for cross-origin assets.

Without TAO, browsers intentionally hide key timing fields for privacy. You might only see limited values in performance.getEntriesByType('resource').

Syntax

Timing-Allow-Origin: *
Timing-Allow-Origin: <origin>
Timing-Allow-Origin: <origin>, <origin>
```text

## How It Works

When a page on `https://app.example.com` loads a script from `https://cdn.example.com`, the browser will only expose detailed timing fields if the CDN response includes an allow rule that matches the page origin.

Example restricted fields when TAO is missing include values used to compute backend/network behavior for that resource.

## Example Responses

Allow any origin:

```http
Timing-Allow-Origin: *

Allow a specific app origin:

Timing-Allow-Origin: https://app.example.com
```text

Allow multiple known origins:

```http
Timing-Allow-Origin: https://app.example.com, https://admin.example.com

TAO vs CORS

TAO does not grant JavaScript access to the response body. It only controls timing visibility for performance APIs.

Use TAO with, not instead of:

• Access-Control-Allow-Origin for cross-origin API access
• Server-Timing for server-side metric breakdowns

Common Mistakes

• Setting TAO on HTML pages but not on the static assets you actually measure
• Forgetting CDN behavior (edge rules can strip or override headers)
• Using TAO when you really need CORS for data access

Security Notes

Timing-Allow-Origin: * is convenient for public static assets, but for private systems prefer explicit origins to reduce cross-site timing exposure.

What Timing-Allow-Origin Unlocks

Without Timing-Allow-Origin, cross-origin resources in the Resource Timing API show zeroed-out values for the most useful timing fields: domainLookupStart, domainLookupEnd, connectStart, connectEnd, secureConnectionStart, requestStart, and responseStart. You can still see duration (total time) and transferSize, but you cannot break down where the time was spent.

With Timing-Allow-Origin set to allow your monitoring origin, all timing fields become available. This lets you measure DNS lookup time, TCP connection time, TLS handshake time, time to first byte (TTFB), and content download time for cross-origin resources. For a CDN-served application, this is the difference between knowing “the font took 200ms” and knowing “the font took 200ms because DNS lookup took 150ms, suggesting a DNS misconfiguration.”

The security consideration is that detailed timing data can be used for timing attacks against cross-origin resources. An attacker who can load your resources from their page and read timing data might infer information about your server’s internal state based on response time variations. For public static assets, this risk is negligible. For authenticated API endpoints, do not set Timing-Allow-Origin unless you have a specific monitoring need that justifies the exposure.