AttestationServer will no longer be using request tokens as part of CSRF protection. It's far simpler to enforce the Origin header always being present and set to attestation.app for the entire API since we avoid using the GET method for anything:
Conversation
Using SameSite=Strict for our login session cookie provides a fallback layer of protection. It's not a full protection by itself since it doesn't protect the login and register methods since we really don't want to have sessions for clients who aren't logged into the site.
1
2
Removes significantly more code than it appears because there's temporary database migration code to get rid of the requestToken field from the Sessions table and SQLite makes that a bit verbose. Can remove the db migration code any time. Just makes upgrades take multiple steps.
Replying to
Entire web API has strict checks for Origin being attestation.app, Content-Type being application/json and Sec-Fetch-Mode/Sec-Fetch-Site being same-origin and Sec-Fetch-Dest being none.
Only having static HTML with strict Trusted Types also helps to rule out issues.
1
3
Each of those 3 checks is a full CSRF protection, although that Content-Type check isn't something you would want to rely on by itself. SameSite=Strict session cookie is close to a 4th and covers everything that actually matters but we don't want sessions for non-logged-in users.
3