FWIW there are real issues with this package today. It is not really impactful for all usage but the security issues are not bogus. If I had a recommendation for today it would be to remove the package from your projects and then for us to deprecate all existing versions. Then as we get things back into a functional place to maintain it we fix the issues and release a new major which would not be deprecated and we roll the folks lagging behind forward.

This is very true. I wouldn't blindly follow Snyk reports, but I mention it in particular (especially it suggesting to use csurf) because from what I understand the reports and info from Snyk were one of the reasons this project was left behind. I may be wrong but it's just what I gather from what limited info I've seen. I don't know if there was an official post about csurf's deprecation that detailed exactly why it is being left in its current state.

I'm happy to hear development may resume in the future. For now, do you recommend any packages in place of csurf, @wesleytodd ?

I do not. Fastify has fixed all the same issues in theirs, but I don't believe that works with express.

I hope we have good replacement for csurf. I want to help but i dont have enough knowledge in security. I will attempt to create one though since need it for apps.

The package is insecure and all you are doing here is setting up a target for security researchers to open up CVEs against. I am going to leave this comment in place because we cannot control what you do with this fork, but to anyone landing here, do not use csurf or a fork as they have known vulnerabilities.

@wesleytodd Somebody still needs to explain me, why is it vulnerable? Explanations I saw in web go along the lines of possibility that an attacker may override the cookie set by csurf, if that attacker controls a sub-domain of protected domain, or he can inject his own code into protected page. Then csurf won't help, as it compares that cookie to the value sent with a request; but to me that reads like a security hole outside csurf, if a bad actor controls a sub-domain, or finds a way to do XSS. And if an attacker can't control a subdomain, or embed his code into the page, then it looks to me csurf protects just enough against CSRF, doesn't it?

Also the deprecation notice on the original csurf reads:

This npm module is currently deprecated due to the large influx of security vulunerability reports received, most of which are simply exploiting the underlying limitations of CSRF itself.

That does not sound to me as authors admitted that csurf is broken and vulnerable as many articles re. csurf claim.

@birdofpreyru https://fortbridge.co.uk/research/a-csrf-vulnerability-in-the-popular-csurf-package/

@wesleytodd, what's the alternative?

@gh0st I saw that, it turns out some security «experts» do not understand well neither security, nor JavaScript 🤣 with just cookie: true option CSURF does a variant of Naive Double-Submit Cookie Pattern, which does its jobs under assumption that malicious parties cannot control sub-domains of the protected domain. That article complains that it does not do Signed Double-Submit Cookie stuff without a more specific configuration, and also the dude got confused about the purpose of «secret» value in that case, which is not supposed to be secret in that scenario, and some other stuff; and also the article ends with the claim that package developers acknowledged the bug and deprecated the package because of it, when in reality developers told that the package is fine, but they are too tired to explain it to amateurs 🤣

So... the original package does its job, or you can use my fork, which got misc necessary maintenance, or you may try to use one of many packages other folks decided to write from scratch, hoping they know what they are doing and have not messed it up.