The Past, Present, and Future of Cross-Site/Cross-Origin Request Forgery
summary
Cross-site forgery is largely neutralized by SameSite cookies for typical cookie-auth apps, but APIs remain vulnerable because forms and fetch can deliver JSON-like payloads when servers accept wrong content types. Demos show form-encoded or fetch attacks creating reviews and messages; real incidents involve dangling CNAMEs and subdomain takeover. Defenses that actually work: synchronizer tokens for legacy apps, require exact Content-Type and use CORS preflight or a custom header enforcer (X-CSRF) + test endpoints to reject text/plain with JSON payloads.
AI-written summary · about
chapters (15)
- 0:00Introduction to Cross-Site Request Forgery
- 1:10What is CSRF
- 5:23Live demo: CSRF attack
- 8:32Introduction
- 10:17Traditional CSRF defenses
- 13:48SameSite cookies
- 18:25Chrome's SameSite default impact
- 21:14CSRF in API apps
- 24:42Live demo: API CSRF
- 29:21CORF explained
- 33:19SameSite vs CORF
- 35:23Content-type vulnerabilities in APIs
- 42:01API defenses: CORS & headers
- 48:19Choosing CSRF defenses
- 50:48Key takeaways
related talks
47mKeynote: Request Forgery on the Web - SSRF, CSRF and Clickjacking
18mWriting an (in)secure webapp
25mWe Still Don’t Have Secure Cross-Domain Requests: an Empirical Study of CORS
36mCSRF Vulnerabilities Are Still Relevant
40mMisconfigured CORS and why web appsec is not getting easier
31mXSS, CSRF, CSP, JWT, Wtf? Idk ¯\_(ツ)_/¯
30mSingle Page Applications: Is your design secure?
18mCORS, XSS, CSRF, SQL injection #BackToTheBasics
