Roadblocks for CSP and Where to Find Them
summary
A qualitative study uses semi-structured interviews, drawing and coding tasks with 12 real-world developers to show many deployed CSPs are trivially bypassable, browsers disagree on features and console messages, and third-party code and legacy inline scripts repeatedly force unsafe choices. Empirical backups include longitudinal crawls of the top sites, a case where reporting caused a DoS, and the example of Airbnb taking three and a half years to harden policy. Recommended fixes: start in report-only mode, move inline code out, use nonces/strict-dynamic and layered policies.
AI-written summary · about
chapters (25)
- 0:00Intro
- 0:38Quick Intro
- 1:41Cross-Site Scripting (XSS)
- 2:59Content Security Policy (CSP)
- 6:14CSP Adoption over time
- 6:50Script Content Control over time
- 7:14Developer Survey
- 8:04Research Questions
- 9:12Methodology
- 10:10Drawing Task
- 11:52Motivations
- 13:31Roadblock: Complexity
- 16:56Roadblock: Information Sources
- 18:02Roadblock: Legacy Code
- 18:46Roadblocks: Different Teams
- 19:42Inline Code / 3rd-Parties
- 21:013rd-Parties - maintenance effort
- 22:47Roadblock: Browsers
- 28:12Problem Solving: Inline Code
- 28:46Problem Solving Strategies
- 29:20Problem Solving: Inline Events
- 30:29Problem Solving: Third Parties
- 31:04How to start with CSP?
- 33:39How to harden my CSP?
- 36:53Conclusion
related talks
53mI Wanna Deploy You, but My Senses Tell Me to ...
47mRestricting The Scripts, You're To Blame, You Give CSP A Bad Name
32mWhat is CSP and Why Haven't You Applied it Yet
51mPushing CSP to PROD
01h 01mA Successful Mess Between Hardening And Mitigation
40mContent Security Policy to the Rescue
01h 00mContent Security Policy: From newbie to advanced
46mContent Security Policies: Let's Break Stuff