Right now CSRF protection is implemented solely by using a CSRF token associated with the client's PHP session. The client must retrieve the token from a web page, either from an embedded form element, or from the global Javascript site variable, and then send it to the server in the request body. The server then checks it against the token stored in the client's session.
This can be a problem for two reasons:
- Requests aren't always made from a web page. In this case a separate request needs to be made to retrieve the CSRF token.
- If the CSRF token is stored in the PHP session, it is lost once the PHP session expires. If this happens while a user is in the middle of filling out a form, they will get a CSRF expiration error and be asked to reload their page (and probably lose all of their form data).
One alternative, or supplemental method we could include, is simply checking for the X-Requested-With: XMLHttpRequest in the request for AJAX requests. See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers
Right now CSRF protection is implemented solely by using a CSRF token associated with the client's PHP session. The client must retrieve the token from a web page, either from an embedded form element, or from the global Javascript
sitevariable, and then send it to the server in the request body. The server then checks it against the token stored in the client's session.This can be a problem for two reasons:
One alternative, or supplemental method we could include, is simply checking for the
X-Requested-With: XMLHttpRequestin the request for AJAX requests. See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers