Safari 27 blocks third-party domains at network level, and how to audit every origin your pages contact

Safari 27 now refuses connections to a category of third-party domains outright, at the network level, with the blocking on by default, according to a post on dev.to. Whatever a team thinks of the policy, the article argues, it leaves everyone with the same question: do our pages contact one of those domains? Most teams cannot answer, and not because they are careless. These domains typically arrive through a tag manager or a marketing vendor, which makes the thing that added them configuration rather than code. Reading the repository reveals nothing, and the answer can change without a deployment.

The network panel is not an audit

The browser's network panel answers the question for one page load, on your machine, along the path you happened to take, with your extensions and cookie state in play. The dev.to author grants that this is useful, but it is not an audit: a request that fires only for signed-in users on a checkout page simply never appears in it.

Resource Timing lists what the page actually fetched

A better local method is the Resource Timing API. Taking the entries returned by performance.getEntriesByType('resource'), mapping each to its origin, dropping your own and deduplicating yields the set of third parties a page really contacted. MDN, cited throughout the article, confirms the API covers XMLHttpRequest, images and scripts alike, and that cross-origin resources do appear in the list. Many timing fields are zeroed for cross-origin resources unless a Timing-Allow-Origin header is set, but the entry name, the only part needed here, stays readable.

That method hides the first of the article's four traps. Per MDN, only 250 resource timing entries are buffered by default, and a heavy page exceeds that easily, with the overflow lost silently. Registering a PerformanceObserver for resource entries with the buffered flag set observes rather than samples, so nothing is dropped.

A report-only CSP covers pages you never visit

Everything above runs where you happen to be standing, which is exactly why the original question is hard to answer. The approach that covers every page and every real visitor is a response header that blocks nothing: Content-Security-Policy-Report-Only. MDN describes it as a way to monitor policy violations and their effects without enforcing the policy, so you can deliberately declare a policy you know is false, such as connect-src 'self', and collect reports of every outbound connection to anywhere else, from production browsers on pages you have never opened.

Three traps sit in this step. The first, which the author says is the one that eats an afternoon: MDN notes that a reporting destination must be specified via the report-to directive for anything to be sent, so a report-only header with no report-to does nothing at all while looking exactly like a policy nothing violates. Second, report-to is the modern directive but does not yet have full cross-browser support; MDN's own example declares it alongside the deprecated report-uri for that reason, and teams that set only the modern one will gather reports from some browsers and wrongly conclude the rest are clean. Finally, MDN states the report-only header is not supported inside a meta element, so deployments where setting response headers is awkward cannot fall back to markup, because the tag is silently ignored.

Why it matters

Any origin on the list can go dark for reasons that never reach you: a browser default, an extension, endpoint security software, a corporate proxy, a network that resolves the domain differently. The blocked request fails inside a browser you have no access to; the server registers nothing, and complete logs reveal nothing. The eventual signal is a user reporting that signing up did not work, with no third party mentioned, because users have no way to see one. An inventory built in advance, which the author estimates takes a single afternoon, converts that report from a mystery into a quick diagnosis, and it costs far less than discovering which third-party dependencies you have at the exact moment one of them vanishes.