John Z Black
Brunswick, ME • (207) 245-1010 • contact@johnzblack.com
You’re logged into your bank. A Taboola tracking pixel fires. It’s on the whitelist. Your Content Security Policy said so.
What your CSP didn’t account for: that pixel hits sync.taboola.com, which returns a 302 Found redirect to www.temu.com/api/adx/cm/pixel-taboola. The browser follows it, no hesitation, with Access-Control-Allow-Credentials: true. Your authenticated banking session just sent its credentials to a shopping app you never consented to contact.
Your CSP never blinked because it doesn’t follow redirects. It whitelists domains. Once sync.taboola.com has permission, whatever it redirects to inherits that permission at the HTTP layer. One hop. That’s it.
Reflectiz researchers documented this in February 2026 and went public this month. Two months of live execution on banking pages before disclosure. Detections confirmed in the EU. US exposure unquantified. PCI DSS Requirement 6.4.3 covers exactly this class of issue. Security teams should already be uncomfortable.
The same playbook showed up in October 2025 with n8n, a legitimate workflow automation platform. Attackers started abusing *.app.n8n.cloud subdomains to fingerprint devices and drop modified remote management tools. By March 2026, webhook abuse was up 686% year over year. n8n didn’t do anything wrong. The infrastructure is legitimate. That’s the point.
A whitelist is a statement of assumed trust, not a security boundary. You’re betting that every domain on the list will always behave as expected, that nothing they run gets compromised, and that none of their infrastructure redirects your users somewhere you haven’t approved. Those are a lot of bets.
Real mitigation means watching actual traffic, not just the first request. Runtime monitoring of third-party behavior on sensitive pages, not static policy declarations, is the only way to catch redirect chains before they execute.
The browser did exactly what you told it to do. That’s the problem.