Is Timing-Allow-Origin * a vulnerability?

On public static files it is usually a RUM choice. On authenticated APIs it is extra telemetry you should justify. It is not the same as ACAO *.

Does RoastMyOpsec check TAO?

No. The CORS check is allowlist vs wildcard on API-shaped responses. Confirm TAO in your CDN if RUM depends on it.

Do I need TAO for CORS to work?

No. They are independent. Set CORS for data access and TAO only if you need detailed Resource Timing.

Vulnerabilities

Timing-Allow-Origin vs CORS for Cross-Origin Telemetry

February 24, 2026

Timing-Allow-Origin vs CORS is two different yeses. CORS (Access-Control-Allow-Origin and friends) is whether another origin's JavaScript may read the body and many headers. Timing-Allow-Origin (TAO) is whether the Resource Timing API exposes detailed timestamps for that request instead of a coarse bucket. A static font on a CDN may send TAO * so first-party RUM can see load times. An authenticated API that also sends TAO * (or CORS *) is donating extra cross-origin telemetry it may not need. RoastMyOpsec's CORS check is about allowlists vs wildcards on API-shaped responses. It does not grade TAO and it does not run timing measurements against you.

The practical difference

CORS is an access-control conversation (including preflight OPTIONS). TAO is a stopwatch conversation. You can allow CORS reads without TAO, and you can unmask timing without allowing the body to be read. Copy-pasting both * from a performance blog is how APIs inherit a CDN static-asset policy.

Resource Timing details are not a substitute for a pentest and not a claim of a specific attack. They are extra data other pages can observe about how your asset loaded.

How to choose based on the resource

Public JS/CSS/fonts you want RUM on: TAO for the origins that run your analytics, or * if the files are truly public and boring. JSON APIs with cookies or tokens: CORS allowlist only; leave TAO off unless you have a documented RUM need. Do not set ACAO * with credentials.

Header	What another origin's JS gets	Typical static CDN	Typical private API
CORS allowlist	Readable body (if allowed)	Often unused	Named origins only
CORS *	Public read, no credentials	OK for truly public JSON	Usually wrong
TAO *	Unmasked Resource Timing	Common for RUM	Usually unnecessary
Neither	Opaque / coarse timing	Fine if you do not need RUM on that host	Healthy default

What the roast can see

Wildcard CORS on app-mode responses is a finding. TAO is not scored. Confirm both at the CDN so HTML, assets, and APIs do not share one header soup. See CORS wildcard vs allowlist.

Common mistakes

The first mistake is TAO * on the same origin as Set-Cookie sessions.

The second mistake is copying a Cloudflare static-asset header pack onto /api.

The third mistake is treating TAO as a CORS substitute.

Free audit the URL you own

RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.

Free audit now

FAQ

Is Timing-Allow-Origin * a vulnerability?: On public static files it is usually a RUM choice. On authenticated APIs it is extra telemetry you should justify. It is not the same as ACAO *.
Does RoastMyOpsec check TAO?: No. The CORS check is allowlist vs wildcard on API-shaped responses. Confirm TAO in your CDN if RUM depends on it.
Do I need TAO for CORS to work?: No. They are independent. Set CORS for data access and TAO only if you need detailed Resource Timing.

Sources

Related guides

Vulnerabilities
CORS Wildcard vs Allowlist for Public APIs
Vulnerabilities
Access-Control-Expose-Headers vs CORS Allow-Origin
News
NEL vs CSP Reports for Public Site Telemetry