@ianopolous @peergos Hi Ian, this is an interesting proposal. CSP can usually not prevent exfiltration of data once untrusted/malicious scripts can be executed in the origin where the sensitive data lives. For example CSP does not restrict navigation and therefore navigating a site (or opening a new window) can be used to exfiltrate data. E.g. navigating to example.com?x=some-data.
However, I don't know your setup so my comment may or may not be accurate here.
You can find more examples on slide 25 here: https://conference.hitb.org/hitbsecconf2018ams/materials/D2T2%20-%20Michele%20Spagnuolo%20&%20Lukas%20Weichselbaum%20-%20Defense-in-Depth%20Techniques%20for%20Modern%20Web%20Applications%20and%20Google%E2%80%99s%20Journey%20with%20CSP.pdf

@we1x @peergos Are you aware of any plans for full exfiltration protection beyond webrtc and prefetch-src? Many groups would love this.

@ianopolous @peergos Full exfiltration protection would be hard to achieve for CSP and is not something CSP was designed for. Furthermore, the proposed navigate-to directive has been deprecated due to security issues it would introduce (iirc the implementation would have allowed certain information leaks): https://github.com/w3c/webappsec-csp/pull/564

@we1x @peergos Great to see the recent work on making prefetch-src implicit (https://github.com/w3c/webappsec-csp/pull/582). I double checked our sandbox setup, and we are able to block iframe navigation and window.open with frame-src CSP and that the subdomain is sandboxed and doesn't have "allow-popup".