Not sure how this implements the Synchronizer Token Pattern

[HQ92]

The docs state that the library implements the synchronizer pattern (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern, https://github.com/pillarjs/understanding-csrf#csrf-tokens).

I'm trying to understand how secure the methods implemented are as OWASP seems to take great pains to say that the CSRF token should not be returned as a cookie, but should be submitted to the server as a header preferably, and if not as a form value. As far as I understand this would then be checked on the server as it would be form and state specific as opposed to a cookie that would be submitted with every request automatically regardless of source. My next thought was then that there seems to be aspects of the double submit pattern in the source code, but this would also require a header submitting the second part to mitigate the issue of cookies automatically being submitted to the server with any request.

By storing both the HMAC value, and the client secret in separate cookies, there seems to be no form specific state that an attacker would need to replicate within their request as these would be auto-submitted to the server on every request. Or am I missing something or have misunderstood how the package works? Is there some sort of way to retrieve the generated csrf from getServerSideProps so that it can be injected as a header into requests going forward?

Are we simply banking on the cookie SameSite flag preventing any cookies being sent with any potentially dangerous requests such as POST?

[j0lvera]

I'm trying to understand how secure the methods implemented are as OWASP seems to take great pains to say that the CSRF token should not be returned as a cookie but should be submitted to the server as a header, preferably, and if not as a form value.

I agree that this needs to be clarified. The understanding CSRF document says: "Don't use an endpoint to get the token; use cookies." OWASP says, "Don't use cookies; send the token in a request param/custom headers," which the latter can be obtained only by exposing an endpoint to get these values (at least in the context of doing this on Next.js).

Implementation details in the OWASP's Cross-Site Request Forgery Prevention sheet are clearer now than they were when I first created this library, so for v2 I'm planning to follow OWASP lead and implement their recommendations.

I will add an RFC soon to discuss these changes.

By storing both the HMAC value, and the client secret in separate cookies, there seems to be no form specific state that an attacker would need to replicate within their request as these would be auto-submitted to the server on every request.

I don't understand your statement; could you clarify please?

[HQ92]

I think I was referring to nothing related to the csrf implementation being form specific. The cookies would be returned with every request to the server regardless of request or source.