Make WordPress Core

Opened 5 years ago

Last modified 9 months ago

#40426 new defect (bug)

Remove dns-prefetch of s.w.org domain

Reported by: joelhardi Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 4.8
Component: Script Loader Keywords: has-patch
Focuses: Cc:


DNS prefetch for the emoji CDN in general-template.php is causing the link tag <link rel='dns-prefetch' href='//s.w.org' /> to be generated on public-facing URLs such as the login/registration page wp-login.php.

This may trigger the user-agent to make a DNS lookup of this domain name which would leak information (for instance) to a rogue DNS resolver. This is a security/privacy concern because it enables discovery or profiling of browsing behavior by anyone operating an upstream DNS resolver.

There does not seem to be a compelling reason to request a dns-prefetch of any hardcoded domain names (even those owned by Automattic) -- I don't believe it is desirable for WordPress core to trigger any unnecessary external network activity by default. An HTTP request to a third-party domain would be a more obvious example, but even a DNS lookup of a FQDN can be used for tracking.

An alternate remedy would be to conditionally insert this <link> tag only when external assets from s.w.org are required, but given the questionable value that dns-prefetch of a CDN domain provides in normal environments (browser, system or local DNS resolver is likely to have already cached this DNS lookup, so dns-prefetch does nothing in the vast majority of page loads) I'd suggest it's simpler to simply remove the hardcoded prefetch insertion. Less code is better in this case.

Please see patch. This is also a net performance improvement since it reduces page size and server processing, but that's secondary.

Plugins, themes or optional components such as emoji support can still trigger resource hints such as prefetch independently, but hardcoding URLs into general-template.php seems like a hack.

Attachments (2)

general-template.php.diff (599 bytes) - added by joelhardi 5 years ago.
patch to remove hard-coded dns-prefetch of s.w.org domain name
40426.diff (653 bytes) - added by sabernhardt 9 months ago.
refreshed patch

Download all attachments as: .zip

Change History (7)

5 years ago

patch to remove hard-coded dns-prefetch of s.w.org domain name

#2 @superpoincare
5 years ago

Another related issue is that if you self host emoji (no CDN), using add_filter to change baseUrl and svgUrl to folders in your own domain, then the code adds a line to dns-prefetch to your own domain.

So if your website domain is example.com, you see a line in the HTML output:

<link rel='dns-prefetch' href='//example.com' />

This isn't needed.

#3 @jhabdas
5 years ago

  • Severity changed from normal to minor
  • Type changed from enhancement to defect (bug)

I'd suggest it's simpler to simply remove the hardcoded prefetch insertion. Less code is better in this case.

Simply put: A page which contains a DNS prefetch to a domain it does not call externally should be considered a bug. I too question the value of dns-prefetch and, in this case, it seems to remove more value than it adds and I'd like to see it removed so I do not need to hack core to optimize page loads (yes, even dead code, even dead code).

#4 @garrett-eclipse
3 years ago

Related - #44001
*If emoji scripts gets internalized due to privacy concerns then the need to prefetch s.w.org will be gone.

9 months ago

refreshed patch

#5 @sabernhardt
9 months ago

  • Component changed from General to Script Loader
  • Keywords has-patch added

I considered making the filter default an empty string (or boolean false), but that wouldn't solve the situation with self-hosted emoji. So I simply refreshed the first patch.

For a temporary fix, I have used the filter to remove the link tag in a plugin:

add_filter( 'emoji_svg_url', '__return_false' );
Note: See TracTickets for help on using tickets.