Clarification of the recommended method to share csrf tokens with the client

[slidenerd]

• Your documentation says dont send the CSRF token as JSON, what does that mean?

const { doubleCsrfProtection, generateCsrfToken } = doubleCsrf({
	cookieName: "_csrf",
	getSecret: () => "",
	getSessionIdentifier: (req) => {
		// Use a combination of IP and User-Agent as session identifier
		return `${req.ip || ""}-${req.get("user-agent") || ""}`;
	},
	ignoredMethods: ["HEAD", "OPTIONS"],
});

const app = express();

app.use(httpLogger);
app.use(helmet());
app.use(cors(corsOptions));
app.all("/api/auth/*", toNodeHandler(auth));
app.use(cookieParser());
app.use(express.json({ limit: "1MB" }));
app.use(express.urlencoded({ extended: true, limit: "1MB" }));
app.get("/", (_req: Request, res: Response, _next: NextFunction) => {
	return res.json({ message: "Hello World" });
});
// IS THIS A BAD IDEA?
app.get("/csrf-token", (req: Request, res: Response) => {
	const token = generateCsrfToken(req, res);
	return res.json({ token });
});
app.get(
	"/encryption/test",
	doubleCsrfProtection,
	(_req: Request, res: Response) => {
		const data = [
			{ id: 1, name: "something" },
			{ id: 2, name: "anything" },
			{ id: 3, name: "nothing" },
		];
		return res.json(data);
	},
);
app.use(notFoundHandler);
app.use(defaultErrorHandler);

export { app };

• Is adding the /csrf-token endpoint above a bad idea?
• If csrf tokens are set on http only cookies, that means the clients wont be able to read them
• Just to clarify, my client is a sveltekit application running on 5173 while express runs on 3002 above and cors origins have been added to make this work
• how do you communicate the tokens if the above statement about JSON is true?

[psibean]

our documentation says dont send the CSRF token as JSON

Ah. That's a confusing line. What it actually means is, "don't send your CSRF token as a cookie", then the comma after that means, "instead". So it means you SHOULD either embed it into the HTML (via a meta tag or form field in the case of SSR), or send it as a JSON response. That comment could use a clarification.

Is adding the /csrf-token endpoint above a bad idea?

As long as you have properly configured the getSessionIdentifier config option it is not a bad idea. The idea is, even if you have a public /csrf-token endpoint, it will return a token that will only ever work for the user who requested it, which means it's safe. CSRF attacks will fail because attackers are unable to request CSRF tokens that will work for other users.

If csrf tokens are set on http only cookies, that means the clients wont be able to read them

Correct, the client shouldn't need to read the cookie, generally speaking, you can override httpOnly to true for "convenience", but it's not all that convenience as you'll also need to parse the cookie value to get the non-hashed version of the token out of it. It should only receive the token via JSON/HTML (or some other response payload content).

If you have a stateful server and you want to have the frontend access the token from a cookie, use csrf-sync for the synchronised token pattern instead.

Just to clarify, my client is a sveltekit application running on 5173 while express runs on 3002 above and cors origins have been added to make this work

For local development, it's generally expected that you will need appropriate CORs configuration to make this work if you're working across ports. In a real deployment, even if you have a huge distributed system, all of that should be hidden in an internal network where the entry point is the same domain. Otherwise you can configure the production CORs policy as appropriate too.

how do you communicate the tokens if the above statement about JSON is true?

The comment is a bit ambiguous, the comma in the sentence is intended to separate the "don't" from the "do".

Apologies for that confusion! I'd expect that the line above it, "sent to the client via a response payload", as well as the examples in the repository would hopefully clear this up over that one line of the comment.