Why CNAME Cloaking No Longer Hides Trackers From Safari or Brave

What is CNAME cloaking?

A tracking vendor uses CNAME cloaking when a site owner points one of the site's own subdomains, such as metrics.example.com, at the vendor's server through a DNS CNAME record, so the browser treats the vendor's requests as first-party. Browsers decide first-party versus third-party by the registrable domain, and a CNAME hides the real destination one layer below the web, in DNS. The vendor gets the cookie access of your own site without appearing as a separate domain.

WebKit's John Wilander explained the effect in a November 12, 2020 post: the third-party domain "is cloaked as sub.blog.example and thus has the same powers as the true first party." The Safari privacy report guide flags CNAME-cloaked endpoints as something to audit.

How does a CNAME record make a tracker look first-party?

A CNAME record makes a tracker look first-party by aliasing a name under your domain to the tracker's hostname before the browser ever sees an IP address, so every check the browser runs sees only your domain. The chain looks like this:

1. The page on www.example.com loads a script or sends a request to metrics.example.com.
2. DNS answers that metrics.example.com is a CNAME for collect.tracker.example.
3. DNS resolves collect.tracker.example to the vendor's IP address.
4. The browser connects, but the URL, the TLS certificate name and the cookie scope all say metrics.example.com.

Two cookie rules make this worth a tracker's effort. Requests to metrics.example.com carry every cookie scoped to example.com, which WebKit says includes "login cookies and user identity cookies." And the response can set new cookies for example.com through a Set-Cookie header, which the browser files as first-party cookies.

That second rule is why trackers pushed the setup. Safari's Intelligent Tracking Prevention deletes cookies created in JavaScript after 7 days without user interaction on the site, which the Safari 7 day cookie limit guide covers in detail. Before November 2020, cookies set by a server in an HTTP response fell outside that cap. WebKit put it bluntly: "Cross-site trackers have convinced site owners to set up CNAME cloaking in order to circumvent tracking prevention."

How does Safari detect CNAME cloaking?

Safari detects CNAME cloaking by comparing the CNAME a first-party subresource resolves through with the site's own domain and the top frame's CNAME, and it caps any cookie set in a mismatched response at 7 days. WebKit shipped the defense in Safari 14 on macOS Big Sur and iOS 14 and iPadOS 14, announced November 12, 2020: "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days."

WebKit defines the trigger exactly: "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists." That last clause covers sites behind a CDN or edge host, where the whole site resolves through a CNAME. WebKit's own table covers those cases:

Main site (www.blog.example)	Tracking subdomain (track.blog.example)	Cookie expiry
No cloaking	No cloaking	No cap
No cloaking	Points at other.blog.example	No cap
No cloaking	Points at tracker.example	7-day cap
Points at abc123.edge.example	No cloaking	No cap
Points at abc123.edge.example	Points at the same abc123.edge.example	No cap
Points at abc123.edge.example	Points at other.blog.example	No cap
Points at abc123.edge.example	Points at tracker.example	7-day cap

The current WebKit tracking prevention page extends the same rule to address tricks that skip DNS names entirely: "ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days." That covers the variant where a subdomain's address record points at a vendor's IP address instead of a vendor hostname.

A cookie from a cloaked response now expires 7 days after it is set, the same limit JavaScript cookies face, so cloaking no longer buys a longer-lived ID in Safari.

How do Brave and uBlock Origin uncloak CNAME trackers?

Brave and uBlock Origin uncloak CNAME trackers by resolving the hostname themselves and checking the canonical name against their tracker filter lists, then blocking the request if the real destination is listed.

uBlock Origin in Firefox. uBlock Origin 1.25.0 added a request for Firefox's dns permission, and its release notes state "From now on uBO will CNAME-uncloak network requests." The feature depends on Mozilla's browser.dns API, and Brave's research team noted that "this solution only works in Firefox, as Chromium does not provide the browser.dns API." The uBlock Origin wiki says the "Uncloak canonical names" setting has been a regular setting since uBO 1.34.0, is "default enabled", and "is currently supported only on Firefox." uBlock Origin on Chrome cannot see the CNAME at all.

Brave Shields. Brave announced CNAME-based blocking on July 20, 2020 and shipped it to all users with Brave 1.17. Brave checks two URLs for every request to a CNAME'd host: "first, the original URL requested by the page, and second, the same URL, but with the CNAME'ed domain name replaced with the resolved 'canonical' domain name." Its example was 16ao.mathon.fr, a first-party-looking subdomain whose canonical name was et5.eulerian.net, a third-party tracker.

One Brave detail trips up site owners. Since version 1.30, Brave's default "standard" Shields mode does not apply network filter lists to same-site subresources, and the "aggressive" mode applies them to "all sub-resource requests, first and third-party alike." Brave's posts do not say how the standard mode treats a cloaked subdomain once uncloaked, so test your own site in aggressive mode before you count on either outcome. Ad blockers and privacy browsers already cut into analytics totals, as the guide on ad blocker effects on analytics accuracy explains. CNAME cloaking does not reliably win that data back.

Three browsers, three responses to a cloaked subdomain

Safari 14 Lets the request through and caps cookies set in the response at 7 days

Brave 1.17 Checks the canonical name against its filter lists and blocks the request if the tracker is listed

uBlock Origin Uncloaks the CNAME and blocks matches in Firefox, but cannot see the CNAME in Chrome

What are the security risks of CNAME cloaking?

CNAME cloaking puts a vendor's server inside your cookie scope, so every cookie your site scopes to the root domain, login and session cookies included, goes to that vendor on each request. That is a privacy risk to visitors and a security risk to you. WebKit's post cites two problems. Site owners who leave a cloaked subdomain in place after ending the contract "risk full website takeovers or customer cookie hijacking if the CNAME records aren't properly managed." It also cites a report of 250 websites "of banks, healthcare companies, restaurant chains, and civil rights groups" compromised through mismanaged CNAME cloaking. A visitor who inspects requests in DevTools also sees only metrics.example.com, with no sign that the data goes to an outside company.

Is a reverse proxy the same as CNAME cloaking?

A reverse proxy is not CNAME cloaking, because your own server receives the request on your domain and forwards it to the vendor, so DNS for that hostname resolves to your infrastructure and not to the vendor's. Under WebKit's definition, cloaking means the subresource "resolves through a CNAME that differs from the first-party domain." A path like example.com/api/track handled by your own web server does not.

The differences that matter for analytics:

Question	CNAME cloaking	Reverse proxy on your server
Where does DNS point?	At the vendor's hostname	At your own server
Who receives your root-domain cookies?	The vendor, directly	Your server, which chooses what to forward
Does Safari cap cookies from the response?	Yes, 7 days	Not under the CNAME or IP cloaking rules
Does Brave or uBO see a tracker domain?	Yes, after uncloaking	No tracker hostname to uncloak, though path-based filter rules still apply
Do you still disclose the vendor?	Yes	Yes

A proxy does not change who processes the data, so a vendor that builds cross-site profiles is the same privacy problem behind either setup. The server side tracking guide covers tagging servers that sit behind a CNAME.

How do you check whether your site uses CNAME cloaking?

You check for CNAME cloaking by listing every subdomain your pages send requests to, resolving each one, and flagging any that resolve to a company you do not run:

1. Open your site in Chrome DevTools, go to the Network panel, reload, and note every request to a subdomain of your own domain that is not your main host.
2. For each one, run dig CNAME metrics.example.com or nslookup -type=CNAME metrics.example.com in a terminal.
3. Compare the answer with your own infrastructure. Your CDN or hosting provider is expected. An analytics, ad-tech or customer data vendor is a cloaked tracker.
4. Check the response headers of those requests for Set-Cookie. A cookie scoped to your root domain from a vendor host is the pattern Safari caps.
5. Delete CNAMEs that point at vendors you no longer use.

How does Flowsery handle proxied setups?

Flowsery's documentation describes a proxy setup, not a CNAME: you proxy the script at /js/main.js and the endpoint at /api/track through your own server, and "Flowsery Analytics auto-detects proxied setups. No data-api is needed if you proxy both /js/main.js and /api/track." The docs publish proxy guides for Next.js, Express.js, PHP, Flask, FastAPI, Vue.js, Nginx, Caddy, Astro, Laravel and DigitalOcean. Flowsery's tracking script runs cookieless with a daily-rotating visitor hash and collects no personal data, so in that mode there is no visitor cookie for Safari to cap in the first place. The privacy-first analytics feature page lists what the tracker stores and what it leaves out.

Frequently asked questions

Does CNAME cloaking matter for cookieless analytics?

Safari's CNAME defense caps cookies, so a script that sets no cookie has nothing for Safari to cap. uBlock Origin on Firefox still resolves the hostname and blocks a cloaked subdomain whose canonical name is on its lists, and Brave runs the same canonical-name check. A cookieless script proxied through your own server gives them no vendor hostname to uncloak.

Does CNAME cloaking bypass ad blockers?

CNAME cloaking bypasses list-based blockers that only see the hostname, which includes uBlock Origin on Chrome. uBlock Origin on Firefox resolves the canonical name and blocks the request when it matches a known tracker, and Brave has run the same check since version 1.17. Safari does not block the request but caps the cookies it sets at 7 days.

Which Safari version added the CNAME cloaking defense?

Safari 14 added it on macOS Big Sur, iOS 14 and iPadOS 14, announced by WebKit on November 12, 2020. The same 7-day cap now also covers third-party IP address cloaking.

Does a CDN CNAME count as cloaking in Safari?

No, not when the CDN fronts your whole site. WebKit's rule exempts a subdomain whose CNAME matches the top frame host's CNAME, so a site and its subdomains on the same edge host keep normal cookie expiry. The cap applies when a subdomain resolves to a different, third-party host.

Is server-side tagging behind a CNAME safe from ITP?

No. A tagging server reached through a CNAME to a vendor's hosted service meets WebKit's definition of third-party CNAME cloaking, so Safari caps cookies from it at 7 days. Running the server on your own infrastructure, with DNS pointing at your own IP, avoids that rule.

How do I remove CNAME cloaking from my site?

Delete the CNAME record for the vendor subdomain in your DNS zone and remove the tags that call it. If you still need the vendor, route its endpoint through a reverse proxy you operate and list the vendor in your privacy notice.

Why do trackers use CNAME cloaking?

The browser treats a subdomain of your site as first-party. Requests to it carry the cookies scoped to your root domain, and the response can set new cookies for that domain. Before November 2020, cookies set by a server in an HTTP response fell outside Safari's 7-day cap.

Does Brave block CNAME cloaking by default?

Brave has checked the canonical name against its filter lists since version 1.17. Since version 1.30, the default standard Shields mode does not apply network filter lists to same-site subresources, while aggressive mode applies them to all sub-resource requests. Brave's posts do not say how standard mode treats a cloaked subdomain, so test your site in aggressive mode.

Does uBlock Origin block CNAME cloaking on Chrome?

Not on Chrome. Chromium does not provide the browser.dns API, so uBlock Origin on Chrome cannot see the CNAME. In Firefox the "Uncloak canonical names" setting is enabled by default and blocks requests whose canonical name matches a known tracker.

What is IP address cloaking?

IP address cloaking is the variant where a subdomain's address record points at a vendor's IP address instead of a vendor hostname. DNS shows no CNAME. WebKit says ITP detects it and caps cookies set in the HTTP response at 7 days, the same as CNAME cloaking.