I have a request that uses a one time token embedded in the page to ensure CSRF protection - an attacker might be able to fool my users into making a illicit request, but they can't get the token, and even if they can it is changed with each request and can expire.
So far, so secure.
I want to implement background-sync with a service worker, so a user can post data offline, and then send that data later when they get a connection.
However, that means that the page isn't available to get the CSRF token, and any token linked with the request when the user builds it may be invalid by the time the data is actually sent.
This would seem to be a general issue with any progressive web site, what is the best practice to handle it?
I think that the background-sync could request a new token, apply it to the data to send and then send it, and that still be a loop that a CSRF attacker couldn't take advantage of, but I'm not certain of that. Can anyone confirm this either way?
At the moment the CRSF tokens ensure that the request has come from a specific page - that's going to have to change for any background process to work. Instead there will have to be some kind of CSRF token service, so we'll only be able to ensure that the user has previously and recently been able to make a request from that service. Is that still adequate protection against CSRF?