Questions Regarding CSRF Token Handling in Next.js Page Router

[nishtha2401]

1. Token Generation Behavior:

   1. When I load my application for the first time, a GET request is made, and a _csrfSecret is stored in the cookies.
   2. When I navigate to pages/first-page, a new CSRF token is generated in the GET response, but the _csrfSecret in the cookies remains unchanged.
   3. When I load another page, pages/second-page, I receive a new CSRF token, but the _csrfSecret cookie stays the same across requests.

Question 1:
If the CSRF token from the first page is still considered valid (because it matches the original _csrfSecret), what is the purpose of generating multiple tokens (one per page load)? Shouldn't the token be consistent as long as the _csrfSecret remains the same?

2. CSRF Token Management Strategy:
   The examples provided in the documentation suggest fetching the CSRF token in the getServerSideProps of each page.

Question 2:
Instead of fetching the token on every page through getServerSideProps, can I fetch the CSRF token once in the _app.tsx using getInitialProps?

My idea is to:

1. Store the CSRF token in a global context using React Context (csrfContext).
2. Use this context to send the token with POST APIs.
3. Since _app.tsx reloads whenever a new page is visited, we only need one token per _csrfSecret to verify the request validity.
4. Would this approach be a valid alternative to generating tokens on every page load?

[amorey]

Question 1:
If the CSRF token from the first page is still considered valid (because it matches the original _csrfSecret), what is the purpose of generating multiple tokens (one per page load)? Shouldn't the token be consistent as long as the _csrfSecret remains the same?

The tokens are salted to generate randomness and mitigate against BREACH attacks.

Question 2:
Instead of fetching the token on every page through getServerSideProps, can I fetch the CSRF token once in the _app.tsx using getInitialProps?

You can fetch the token once (e.g. on initial page load) and use it for all your POST requests so your approach should work. Actually, I looked into adding a React context-helper to the library a while ago but at the time I couldn't figure out a way to make it developer friendly. If you like your approach and it's easy to share, it'd be a great addition to the library.

[nishtha2401]

Global solution for managing the CSRF token using React Context and the _app.tsx file. Below are the key parts of the code:

csrfContext.tsx

import { createContext, useContext, ReactNode } from "react";
import { types } from "./definitions";

interface CsrfProviderProps {
  children: ReactNode;
  csrfToken: string;
}

// Create a context to provide the CSRF token globally
const CsrfContext = createContext<types.CsrfContext | undefined>(undefined);

export const CsrfProvider: React.FC<CsrfProviderProps> = ({ children, csrfToken }: CsrfProviderProps) => {
  return <CsrfContext.Provider value={{ csrfToken }}>{children}</CsrfContext.Provider>;
};

export const useCsrf = () => {
  const context = useContext(CsrfContext);
  if (!context) {
    throw new Error("useCsrf must be used within a CsrfProvider");
  }
  return context;
};

_app.tsx

import { CsrfProvider } from "context/CsrfContext/csrfContext";
import App from "next/app";
import type { AppContext, AppProps } from "next/app";

function Application({ Component, pageProps, csrfToken }: AppProps & { csrfToken: string }) {
  return (
    <CsrfProvider csrfToken={csrfToken}>
      <Component {...pageProps} />
    </CsrfProvider>
  );
}

// Fetch the CSRF token and pass it to the CsrfProvider
Application.getInitialProps = async (appContext: AppContext) => {
  const appProps = await App.getInitialProps(appContext);
  const csrfToken = appContext.ctx.res.getHeader("x-csrf-token") || "missing";
  return {
    ...appProps,
    csrfToken,
  };
};

export default Application;

useFetch Hook

import { useCsrf } from "../context/CsrfContext/csrfContext";

function useFetch() {
  const { csrfToken } = useCsrf(); // Access the CSRF token from the context

  async function fetchApi(url: string, method: string = "GET", body?: any) {
    const headers: HeadersInit = {
      "Content-Type": "application/json",
      ...(method !== "GET" && { "x-csrf-token": csrfToken }), // Attach CSRF token for non-GET requests
    };

    const response = await fetch(url, {
      method,
      headers,
      body: body ? JSON.stringify(body) : undefined,
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    return await response.json();
  }

  return { fetchApi };
}

export default useFetch;

1. Do you think this implementation is secure?
2. Are there any potential security vulnerabilities or improvements you would recommend?

[nishtha2401]

Currently, I understand that the _csrfSecret remains the same in cookies across multiple GET requests, even though each request provides a new CSRF token.

What I’m thinking is:

1. Every time a GET request is made from the client-side, a new _csrfSecret should be stored in the cookies.
2. Along with this new _csrfSecret, a new CSRF token should also be sent in the response headers.
3. When the POST request is made, it should use the latest token and _csrfSecret from the most recent GET request.
4. If a POST request is sent using a CSRF token and _csrfSecret from a previous GET request, it should fail verification.

Question

1. What do you think about this approach?
2. Would this provide better security, or do you see any downsides or challenges with this implementation?

[amorey]

1. Every time a GET request is made from the client-side, a new _csrfSecret should be stored in the cookies.
2. Along with this new _csrfSecret, a new CSRF token should also be sent in the response headers.
3. When the POST request is made, it should use the latest token and _csrfSecret from the most recent GET request.
4. If a POST request is sent using a CSRF token and _csrfSecret from a previous GET request, it should fail verification.

1. Edge-CSRF sets the _csrfSecret cookie on the initial GET request and this value doesn't change until the browser itself expires the cookie
2. On the inital request and every subsequent GET request, Edge-CSRF generates a new signed token based on the value of _csrfSecret and adds it to the response headers
3. Tokens don't expire so a POST can use any token generated by Edge-CSRF for a given _csrfSecret.

1. What do you think about this approach?
2. Would this provide better security, or do you see any downsides or challenges with this implementation?

What are you trying to do? I thought you were going to use a React context in order to make a token available to your entire app but it sounds like you're considering making changes to the implementation itself. In terms of implementation, this library uses the signed double-submit cookie pattern described here. This pattern is well vetted so I'd be hesitant to take a different approach because you could introduce security holes into your app accidentally.

[nishtha2401]

Global solution for managing the CSRF token using React Context and the _app.tsx file. Below are the key parts of the code:

csrfContext.tsx

import { createContext, useContext, ReactNode } from "react";
import { types } from "./definitions";

interface CsrfProviderProps {
  children: ReactNode;
  csrfToken: string;
}

// Create a context to provide the CSRF token globally
const CsrfContext = createContext<types.CsrfContext | undefined>(undefined);

export const CsrfProvider: React.FC<CsrfProviderProps> = ({ children, csrfToken }: CsrfProviderProps) => {
  return <CsrfContext.Provider value={{ csrfToken }}>{children}</CsrfContext.Provider>;
};

export const useCsrf = () => {
  const context = useContext(CsrfContext);
  if (!context) {
    throw new Error("useCsrf must be used within a CsrfProvider");
  }
  return context;
};

_app.tsx

import { CsrfProvider } from "context/CsrfContext/csrfContext";
import App from "next/app";
import type { AppContext, AppProps } from "next/app";

function Application({ Component, pageProps, csrfToken }: AppProps & { csrfToken: string }) {
  return (
    <CsrfProvider csrfToken={csrfToken}>
      <Component {...pageProps} />
    </CsrfProvider>
  );
}

// Fetch the CSRF token and pass it to the CsrfProvider
Application.getInitialProps = async (appContext: AppContext) => {
  const appProps = await App.getInitialProps(appContext);
  const csrfToken = appContext.ctx.res.getHeader("x-csrf-token") || "missing";
  return {
    ...appProps,
    csrfToken,
  };
};

export default Application;

useFetch Hook

import { useCsrf } from "../context/CsrfContext/csrfContext";

function useFetch() {
  const { csrfToken } = useCsrf(); // Access the CSRF token from the context

  async function fetchApi(url: string, method: string = "GET", body?: any) {
    const headers: HeadersInit = {
      "Content-Type": "application/json",
      ...(method !== "GET" && { "x-csrf-token": csrfToken }), // Attach CSRF token for non-GET requests
    };

    const response = await fetch(url, {
      method,
      headers,
      body: body ? JSON.stringify(body) : undefined,
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    return await response.json();
  }

  return { fetchApi };
}

export default useFetch;

1. Do you think this implementation is secure?
2. Are there any potential security vulnerabilities or improvements you would recommend?

This is what I have implemented in my project.
I have use context here, is this implementation correct ? And it doesn't brings any security concern right ?

[nishtha2401]

Currently, I understand that the _csrfSecret remains the same in cookies across multiple GET requests, even though each request provides a new CSRF token.

What I’m thinking is:

1. Every time a GET request is made from the client-side, a new _csrfSecret should be stored in the cookies.
2. Along with this new _csrfSecret, a new CSRF token should also be sent in the response headers.
3. When the POST request is made, it should use the latest token and _csrfSecret from the most recent GET request.
4. If a POST request is sent using a CSRF token and _csrfSecret from a previous GET request, it should fail verification.

Question

1. What do you think about this approach?
2. Would this provide better security, or do you see any downsides or challenges with this implementation?

I am not implementing this in my project. Just wanted to discuss this approach.

[amorey]

I don't see any security issues with your CSRF context implementation. You're fetching the token server side and making it available to the app internally client-side which is fine.