Root issue is that WebKit violates the specification for Content-Security-Policy (CSP) violation reports, leaking the destination of a violating redirect rather than the origin in the documentURI field of the report.

This may sound like a rather benign issue, but it can be used to great effect against OAuth implementations for example. During a normal OAuth authorization code flow, once a user has been validated by the OAuth provider (like Google, Facebook, Apple, etc) they will be redirected back to the source application with an authorization code in the URL parameters. If that redirection causes a CSP violation, the report generated for it will leak the authorization code on WebKit-based browsers.

An attacker can create this situation through a maliciously crafted CSP policy on their own page, that allows a request to the authentication provider, but not to the final redirect destination, and set themselves up to catch violation report, leaking the authorization code when the violation happens.

This does require that the victim-page automatically redirect without user-interaction, this is a normally the situation when a user has previously authorized the application, but otherwise is fairly effective. This is also dependent on the victim user visiting an attacker controlled page, but given that the attack itself does not need to be targeted at a specific user, its still quite damaging.