CSRF functionality in Redwood

ramandhingra · March 4, 2022, 9:14am

Hi @dthyresson It s good to hear from you.

Actually, the main middleware I am looking for is one that implements the CSRF protection. I used these two Express middleware before and they are proven middlewares.

The cookie-parser middleware must be placed before csurf. And what csurf does is the following: Creates a CSRF token and validates an incoming request against that token. This middleware adds a req.csrfToken() function to make a token which should be added to requests which mutate state, within a hidden form field, query-string etc. This token is validated against the visitor’s csrf cookie.

I need to protect almost all GraphQL endpoints including login and register.

According to my opinion, this token should be issued when a user requests the index.html (JAM stack, residing somewhere in CDN) for the first time. Now for all subsequent requests, the client sends the CSRF token with all requests.

How can we implement this in Redwood. Kindly tell me. Thanks.

As a side note, Fastify allows us to use the Express middleware. Also, the Express middleware are simply functions.

It’d be great if the Redwood uses these two middleware functions to provide the CSRF functionality out-of-the-box.

dthyresson · March 4, 2022, 4:31pm

@ramandhingra I just want to make sure you are aware of a few things:

Fastify is only used when you deploy Redwood in a serverful manner – Fastify is not used when you deploy to Netlify or Vercel (these serverless functions can use Middy
You can configure Fastify as shown here: App Configuration | RedwoodJS Docs
I’m not certain we’ve exposed a way to add Fastify plugins, however. But, if your concern is plugins for the GraphQL handler, since this is a lambda function ( that Fastify knows how to handler), I think using Middy as middleware is a reasonable option, see below.
CSRF is already done if you use dbAuth. See redwood/packages/api/src/functions/dbAuth/DbAuthHandler.ts at 15b4c9edffc56bacaffc1b45d5000a5dfb9c01a0 · redwoodjs/redwood · GitHub

I need to protect almost all GraphQL endpoints including login and register.

Redwood does this via the @requireAuth directive automatically. Though maybe you are creating som custom authentication scheme?

Redwood enforces auth using an envelop plugin for the graphQL server, see here: redwood/packages/graphql-server/src/plugins/useRedwoodAuthContext.ts at main · redwoodjs/redwood · GitHub

The key point is to:

extendContext({ currentUser })

such that the api side global context will have a currentUser set.

Perhaps you will want to create you own custom plugin to handle your auth case?

In here you can fetch the cookie for the event headers and authenticate as needed.

rob · March 4, 2022, 5:00pm

Slight correction: CSRF is only half-done in dbAuth—I couldn’t figure out where to add arbitrary headers (like a csrf-token header) to every GraphQL request, including those for currentUser. There’s an open issue here: https://github.com/redwoodjs/redwood/issues/3075

dthyresson · March 4, 2022, 5:18pm

I wasn’t aware of that since I don’t often use dbAuth in my apps, but I added some ideas of how you might accomplish tis to the issue

ramandhingra · March 4, 2022, 6:35pm

Okay fine. Just to make sure, Fastify is used when we deploy an app on AWS. And for this purpose, you wrote the following. Am I right?

github.com

redwoodjs/redwood/blob/main/packages/api-server/src/requestHandlers/awsLambdaFastify.ts

import type {
  APIGatewayProxyResult,
  APIGatewayProxyEvent,
  Handler,
} from 'aws-lambda'
import type { FastifyRequest, FastifyReply } from 'fastify'
import qs from 'qs'

import { mergeMultiValueHeaders, parseBody } from './utils'

const lambdaEventForFastifyRequest = (
  request: FastifyRequest
): APIGatewayProxyEvent => {
  return {
    httpMethod: request.method,
    headers: request.headers,
    path: request.urlData('path'),
    queryStringParameters: qs.parse(request.url.split(/\?(.+)/)[1]),
    requestContext: {
      requestId: request.id,

This file has been truncated. show original

Storing a CSRF token in the db means that we need to hit the db everytime a resolver is executed. The CSRF protection can be implemented in a stateless manner too. As stated in the following link, there is a double submit cookie pattern for the same.

The next-auth also uses the same method. It is stated in this Readme
https://github.com/nextauthjs/next-auth/blob/main/docs/docs/getting-started/rest-api.md

rob · March 4, 2022, 7:02pm

As stated above, CSRF protection is not actually implemented in dbAuth yet. But, even when it is, CSRF tokens will not be stored in the database, they’re implemented as request headers combined with a token encrypted into your auth session cookie.

ramandhingra · March 4, 2022, 7:10pm

@rob

CSRF in dbAuth (database) made me assume that they are getting stored in db. If possible, use the csurf and cookie-parser modules to implement it. These modules further use several other modules to make CSRF work perfectly.