Server routes /api/auth/* should always return a Cache-Control header set to no-store

[zmarty]

Description 🐜

This is somewhere in between a bug and a feature request, but since I think this is a security risk I'm opening it as a bug.

Let's say you place a Next.js website using NextAuth behind a CDN that performs caching for you. Some CDNs assume that if a response does not contain a Cache-Control header, then they should go ahead and cache the request anyway.

Azure FrontDoor is one example. In this documentation it says: If no Cache-Control is present, the default behavior is that Front Door will cache the resource for X amount of time where X gets randomly picked between 1 to 3 days.

Since endpoints such as /api/auth/session do not currently return a Cache-Control header, FrontDoor caches the result. This is a major security risk because it will end up caching the information of a different user.

There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton

Temporary workaround

I want to stress that in my opinion the workaround below is not a valid reason to close this bug. NextAuth should do the right thing by default.

In next.config.js you can define custom headers:

async headers() {
  return [
    {
      // Force disable caching for any NextAuth api routes. We need to do this because by default
      // these API endpoints do not return a Cache-Control header. If the header is missing, FrontDoor
      // CDN **will** cache the pages, which is a security risk and can return the wrong user:
      // https://docs.microsoft.com/en-us/azure/frontdoor/front-door-caching#cache-expiration
      source: '/api/auth/:slug',
      headers: [
        {
          key: 'Cache-Control',
          value: 'no-store, max-age=0',
        },
      ],
    },
  ];
},

Is this a bug in your own project?

No

How to reproduce ☕️

Build a Next.js website with NextAuth, then make a request to /api/auth/session. Notice there is no Cache-Control header returned.

Screenshots / Logs 📽

No response

Environment 🖥

next 11.0.0
next-auth 3.14.0

Windows
Node 16

System:
OS: Windows 10 10.0.19043
CPU: (12) x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
Memory: 44.28 GB / 63.85 GB
Binaries:
Node: 16.5.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.10 - s:\SOME_PROJECT\node_modules.bin\yarn.CMD
npm: 7.19.1 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: Spartan (44.19041.1023.0), Chromium (91.0.864.70)
Internet Explorer: 11.0.19041.1
npmPackages:
next: ^11.0.0 => 11.0.0
next-auth: ^3.14.0 => 3.20.1
react: ^17.0.2 => 17.0.2

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[balazsorban44]

It actually happened to me as well! 😳

vercel/next.js#14136

Still a bit torn about this if we should blame it on bad CDN defaults or add it to next-auth.

I would like to wait and see if there is interest in this issue by others. Thanks for reporting!

[Fronix]

This exact thing happened to be as well. I've solved the issue also by adding no-store, max-age=0 in next.config.js for now. Either a simple config or a FAQ regarding this might be enough.

[ZakKa89]

Thank you for this, definitely a use case for us as well.

[parhamey]

It actually happened to me as well!!

[thwonghin]

About the workaround: You might want to override the header in the next API handler instead of in next.config.js. As mentioned here in the doc the Cache-Control header will be overridden in production (In my case, Vercel) unless you are setting it right in the handler.

// In api/auth/[...nextauth].ts

import NextAuth from 'next-auth';
// ...

export default async function auth(req: NextApiRequest, res: NextApiResponse) {
  res.setHeader('Cache-Control', 'no-store, max-age=0');
  return NextAuth(req, res, authOption);
}

[balazsorban44]

I concluded that this is not our responsibility. Next.js already won't cache API Routes, if it does, it should be discussed on the Next.js repo or with the underlying CDN provider you are using.