As pointed out by Adam in bug 69353, we should be blocking redirect of XHR, EventSource and WebSockets if there is a connect-src directive.
Actually, I don't think WebSockets support redirects, but the other two do.
This is made slightly complicated by the fact that we don't get a chance to stop redirects in the same class that started the load. I am told this is because we don't want to block an XHR on a worker from making progress, so all policy information has to be on the ThreadableLoader itself.
One way we could do this is to make ThreadableLoader aware of either the whole ContentSecurityPolicy object (making access to it safe from multiple threads). Another is to just have a way to copy the relevant part of the policy into the loader, and have a mechanism for it provide reports. There may be other ways, but I am currently leaning toward making the ContentSecurityPolicy thread safe.
Adam, your comments are appreciated.
I would just teach DocumentThreadableLoader about ContentSecurityPolicy. It might be worth keeping the check you have in XMLHttpRequest.cpp so we can throw an exception in the non-redirect case. In the redirect case, we can just treat it as a network error.
This isn't likely to be fixed for CSP 1.0.