PortSwigger’s post walks through attacks that use CSS, HTML quirks, and browser behavior to exfiltrate data from HTML email and interact with surrounding webmail UI without relying on JavaScript inside the message body. The targets named in the writeup include Gmail, Fastmail, ProtonMail, Slack, and Cowork. The core point is not just that HTML email is messy. It is that “CSS-only” content can still become active attacker-controlled logic once a webmail app renders it inside a larger trusted page.
The discussion landed hard on architecture. The strongest practical answer was strict isolation with sandboxed iframes. Several people treated that as the obvious first line of defense for any user-submitted content, not a nice extra. There was also broad agreement that email rendering remains a compatibility swamp. HTML email still leans on tables, support differs sharply across clients and even between desktop and mobile versions of the same client, and that stagnation makes secure sanitization harder, not easier.
The mood was openly hostile to HTML email itself. A lot of people argued that allowing rich email imported the browser threat model into inboxes without the discipline browsers evolved over time. Others pushed that this is not a realistic place to take a purity stand because commerce and ordinary business workflows depend on formatted mail. A smaller but important correction was that the post’s hash-based exfiltration example looked technically off, since URL fragments are not sent to servers. That did not kill the broader finding, but it did dent confidence in parts of the demo. Separate side chatter focused on the irony that the article site itself leaned on JavaScript and had browser-history issues on Safari.
If your product renders user-supplied HTML, email or otherwise, isolate it like hostile code rather than treating CSS as harmless formatting. For leaders choosing email infrastructure, plain text or native clients reduce this class of risk, while browser-based inboxes keep inheriting the web’s attack surface.
Concerned and annoyed. Most commenters found the research believable at a high level and saw it as more evidence that HTML email is a security and privacy mess, with extra frustration directed at webmail vendors and at how hard it is to get fixes triaged.
Key insights
01
Sandboxed iframes as the baseline
Sandboxed iframes were framed as the default containment boundary for any untrusted message body, because they cut off the rendered email from the surrounding application instead of hoping sanitization catches every CSS and HTML trick. That sharpens the lesson from the research. The failure is architectural before it is a bad filter rule.
If your app shows user-authored HTML anywhere near privileged UI, move isolation down into the rendering boundary. Review whether your current sanitizer is standing in for a sandbox you should have built instead.
Email HTML remains stuck with table layouts and wildly inconsistent feature support across clients, even between desktop and mobile builds of the same product, as the Can I Email scoreboard shows. That matters here because broken and fragmented rendering rules create more weird corners for attackers and more exceptions for defenders.
Treat HTML email support as legacy compatibility work, not as a solved browser problem. Budget extra testing and expect security fixes in one client or platform not to transfer cleanly to another.
The writeup’s example of sending stolen data via the URL fragment raised a real credibility issue, because the fragment is handled by the browser and normally never reaches the server. That does not erase the larger class of attacks, but it is a reminder to separate a valid attack surface from a shaky proof of concept.
Read flashy security demos for mechanism, not just conclusion. If you are using this post to justify engineering work, validate the exact exploit path before scoping the fix or communicating impact.
Google’s contractor-heavy user issue triage was called out as a reason obvious security reports can stall before reaching the engineers who own the rendering model. That shifts some blame from any single bug to the reporting pipeline itself. A brittle inbox plus weak escalation is how “known weirdness” becomes long-lived exposure.
If you run a platform with user-generated content, audit how security reports actually reach product engineers. A good sandbox on paper is not enough if the organization cannot recognize when it is failing.
Rejecting HTML email is not operationally realistic
Blanket advice to ignore HTML mail was called dangerous because many jobs depend on messages whose meaning, branding, or workflow breaks when reduced to plain text. That cuts against the dominant purist view. The practical problem is not whether HTML email is bad in theory. It is how to contain it without breaking normal business communication.
Do not base policy on the assumption that users can simply opt out of HTML mail. Build safer defaults and clearer isolation for the cases people cannot avoid.
The claim that HTML email just appeared with no standards thinking was pushed back on. MIME predated HTML, and there were attempts in the Internet Engineering Task Force to define a constrained HTML profile for email before the effort collapsed. That makes the ecosystem look less like pure negligence and more like a standards failure followed by vendor drift.
When a risky format survives for decades, assume path dependence and failed coordination, not just one bad vendor decision. That usually means migration plans will be harder than technical purists expect.
portswigger.net