A few months ago I watched a bot POST to /admin/videos/delete on a staging box and wipe a test playlist without ever authenticating a form. The request carried a valid session cookie — because the browser attaches cookies to any request to our origin — and my admin panel happily trusted it. That is CSRF in its purest form, and it is embarrassingly easy to trigger against a PHP video panel where every "approve", "delete", and "promote to homepage" action is a state-changing POST guarded only by a login session.
I run the backend for ViralVidVault, a European viral-video discovery service, and our admin panel is where editors approve trending clips, tune category weights, and flush caches. Those endpoints are exactly the kind of high-value, cookie-authenticated actions that CSRF targets. This article walks through how we protect them with the double-submit cookie pattern on PHP 8.4 — why we picked it over server-side synchronizer tokens, the signing detail almost every tutorial gets wrong, and the exact code running in production behind LiteSpeed and Cloudflare.
Why double-submit instead of session-stored tokens
The classic "synchronizer token" pattern stores a random token in the server-side session and compares it against a hidden form field. It works, but it has an operational cost that matters at our scale:
