Hasty Treat - Target=_blank security issue? What's the deal with noopener and noreferrer?

Episode Summary

Executive Summary: The episode explains why links with target="_blank" can expose the opener window to security risks, and why developers should add rel="noopener noreferrer"—though modern browsers are increasingly handling noopener by default. Wes and Scott discuss the security, analytics, and legacy-use-case tradeoffs, and note that browser behavior is evolving toward safer defaults.

Main Topics: What noopener and noreferrer do: They explain that target="_blank" links can let the opened page access window.opener, and that noopener prevents this while noreferrer also strips referrer data. Why this is a security issue: The hosts describe how a malicious site could use access to the opener window to inspect or manipulate the original page, making it a cross-site risk. Real-world use cases and legacy patterns: They discuss legitimate but uncommon reasons for opening new windows and controlling the opener, such as coupon sites, pop-up workflows, and older banking or media interfaces. Browser behavior and evolving defaults: They note that Safari and Firefox appear to handle noopener by default for _blank links, while Chrome and Chromium-based browsers still require explicit attributes at the time of recording. Analytics and referrer tradeoffs: They explain that noreferrer can protect privacy/security but removes referrer headers, which may reduce analytics visibility and affect referral tracking systems that rely on referrer data. Developer ergonomics and the value of curiosity: The conversation highlights how small browser quirks add cognitive load and how questioning default practices can reveal important security and platform changes.

Key Arguments: target="_blank" can expose window.opener, allowing the opened site to interact with the originating page. rel="noopener" nulls out window.opener, preventing the new page from reaching back into the opener. rel="noreferrer" additionally strips the referrer header, which can protect privacy but also breaks referrer-based analytics. Browsers are moving toward safer defaults, so the manual workaround may become less necessary over time. Some older workflows used pop-ups or opener control legitimately, but many of those patterns are now obsolete in modern web apps. Adding the attributes blindly can have business consequences, especially for analytics and referral tracking.

Data Points: Recording date reference: June 26 - Scott notes that, as of the recording date, Chrome still allowed the unsafe behavior while other browsers were changing. Browser support trend: Safari for about a year; Firefox now appears to do this too - Wes reports that these browsers infer noopener by default for target="_blank" links. Sponsor offer: 2 months free - Sentry promotion with coupon code "tasty treat". Coupon code: tasty treat - Mentioned in the Sentry sponsor segment. Family-size old site example: ~12 workers - Scott references an agency jukebox feature used by a small agency team.

Pivotal Quotes: "if you have a link that has a target of underscore blank... the website that you link to... will have access to the window of the opener website" — Wes Boss: Explaining the core security problem with target="_blank" links. "I thought, okay, why is this obviously a security issue in the browser? Why don't browsers just fix it?" — Wes Boss: Introducing the central question behind the discussion. "there's so many times that little things like that pop into my brain where I get curious about something, and then it just be a perfect opportunity to learn out loud" — Scott Tolinski: Reflecting on the value of public learning and curiosity.

Implications: Developers should keep using rel="noopener" and often rel="noreferrer" today, but should expect browsers to keep hardening defaults. Teams should balance security with analytics needs and audit any code that depends on opener/referrer behavior.