Jean-Charles Sisk

I can think of a couple of reasons. The biggest one would be that query params are passed in referer headers. You'd be exposing the token to 3rd parties. Exploiting...

> The token should be invalid by then. Unless this library doesn't invalidate the token after it's been used. We do not. Tokens are valid for the life of the...

This can be summarized fairly succinctly with this: [OWASP recommends against it](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL). They have several paragraphs dedicated to the subject. > The ideal solution is to only include the CSRF...

Ah. Gotcha. Thanks for framing the problem for me. Let me give it some thought today and get back to you. I'm certain we can come up with something.

Leaving this issue open for now but continuing the conversation in expressjs/multer#195 until I can provide a functional solution.

The best solution is still to ensure multer parses the body before the csrf check. There's an [example of that in the multer thread](https://github.com/expressjs/multer/issues/195#issuecomment-129568691). If using kraken, multipart parsing (by...

Not a silly question. :grinning: Yes, it will still be protected if the body is being parsed in the right order (multipart parsing followed by csrf checking). Accord to the...

My pleasure. :grinning:

Cool with the pseudoRandomBytes stuff (though it's still better than the original Express implementation which used Math.random, iirc). Regarding the the concatenation, we just emulated the Express implementation. I'd support...

With the default token implementation, there is no way to first-class mechanism to invalidate the token. Invalidated only at the terminus of the session is sufficient as far as OWASP...