Yeah, this article doesn't make sense to me.
As I understand double-submit CSRF protection, it works like this:
The CSRF token is included in an HTTPOnly cookie, and it's also included in the page content itself. That can be in an HTML form that gets posted, or in an in-page script tag that sets the cookie on a global JavaScript object, or whatever.
Then the client sends the second, accessible version of cookie in a request parameter or HTTP header, and also (automatically) sends it as one of the cookies. The server just has to check that the token in the param or header matches the token in the cookie. The server doesn't have to remember the token value, so there's no required server-side state here.
I am far from a security expert, though.
As I understand double-submit CSRF protection, it works like this:
The CSRF token is included in an HTTPOnly cookie, and it's also included in the page content itself. That can be in an HTML form that gets posted, or in an in-page script tag that sets the cookie on a global JavaScript object, or whatever.
Then the client sends the second, accessible version of cookie in a request parameter or HTTP header, and also (automatically) sends it as one of the cookies. The server just has to check that the token in the param or header matches the token in the cookie. The server doesn't have to remember the token value, so there's no required server-side state here.
I am far from a security expert, though.