Crazy Sloppiness in X.com Content Security Policy

First let's define CSP, Content Security Policy. In simple terms, CSP is a browser-side firewall: it lets websites tell the browser exactly which domains it may load scripts, images, or exchange data with; blocking rogue code and data leaks. In my book, it’s one of the greatest inventions of the modern web.

When configured well, CSP can make your web app practically immune to XSS and data exfiltration.

A few weeks ago I was pondering if allowing “.yourdomain.com” or “.thirdparty.com” wildcards in CSP was risky, especially if you run side projects on sub-domains. A marketing microsite left to rot for years, with user upload capability could become an attacker’s exfil gateway.

Curious, I wondered how the big players handled their CSP. Were they whitelisting entire subdomain trees? I opened the dev console. First check: X… and to my surprise, I found hundreds of domains in their CSP.

I pasted the list into Grok and asked it to flag anything suspicious, and indeed, it found a few "connect-src" directives whitelisting three SnappyTV sub-domains, an old video product Twitter shut down in 2019.

The gotcha is that the domain expired in 2023 and is now controlled by unrelated third party pushing Korean casino ads. (see screenshots here https://x.com/plehoux/status/1961170683439853875)

That means if the new owner of this domain is a bad actor, with the right XSS, they can exfiltrate data from X, all with CSP's blessing.

I reported the finding through X's bug-bounty program. Their verdict: “best practice, not a vulnerability.” Maybe true in isolation, but still crazy they are not cleaning the mess (reported 45 days ago).

“Not exploitable today” can become “critical tomorrow” when conditions align.

I mean X threat model must include state actors...

I would suggest a business to:

1. Never let any business domain name expire. 2. Have their most conspiracist developer review their CSP on a recurring basis.

I'm crazy or, shouldn't this be fixed ASAP?