CSRF tokens means you cannot resubmit a tedious form to test new deployed fixes

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the web-development category.

Last Updated: 2024-04-24

There was a problem with uploading an applicant CV data blob with the project B code after I switched the s3 buckets.

Since I could not get the development code running on my own machine, the only way to confirm this bug was on production. But unfortunately the form was HUGE and had many validations.

I spent a few minutes filling it in and, sure enough, saw the error.

I wrote what I believed to be a fix and deployed my code. Soon after the deploy, I hit refresh in the browser to resubmit the post request with the same data.

It failed again, and because there were no error logs of any kind set up (I was brought in to rescue this junior programmer's work), I assumed the error was because I had not fixed the permissions issue with my bucket.

But, in fact, the real reason it failed was because the CSRF tokens did not match between deploys. I was using the token from the previous form (which was based on my session). But, post deploy, I had a new session ID, and therefore the web application cried foul.

Lesson

When testing if something is fixed in production web applications and without access to error logs, you need to clear the cache and generate a new form, filling it out from scratch again to avoid CSRF issues (alternatively, modify the token manually)