Security scan recommendations from observatory.mozilla.org

[ondrejkralik]

Hello,
maybe this question should be in next-auth project, but it is connected with this site, so I put it here.

Do you know about this site?
https://observatory.mozilla.org/analyze/nextjs-starter.now.sh
Maybe it can help you with improving security settings of next-auth example page and nextjs-starter site too. Something could be solved with vercel/next.js#4943

FYI I'm currently solving the problem of how to store JWT in SPA written in next.js & redux, so I'm checking all resources which could help me (including yours projects). For me it is most important vercel/next.js#153

My current solution is to store JWT in redux store (for client API requests) & in httpOnly secure cookie (for server API requests).
But I not sure with one thing. If it is OK that JWT token (which is put from cookie into the redux store by server during the first server render) is actually stored in window.__NEXT_DATA__ which could be easy accessed from potential malicious XSS. Maybe I should ask in vercel/next.js#153 too.

[iaincollins]

Hi there, thanks that's an interesting tool from Mozilla and I hadn't seen it before.

I probably won't add more to the next-auth example – as next-auth is already more complicated than it needs to be and I want to try and make things easier for folks by keeping the noise down – but it's interesting for nextjs-starter project and might be worth including some hardening tools for if there as some easy options to include by including an additional library for CORS, etc.

(I probably won't try to address all of those issues specifically – some of them are not relevant and Mozilla Firefox doesn't support all those headers – but it's interesting and helpful to have a good practice example of useful headers to have set, especially for folks building more complex sites.)

Regarding tokens readable in JavaScript:

So, there is a solution to this. It's a bit of a pain, but I take this approach on other services that need to do privileged operations in JavaScript (in my case, websockets). I use it with next-auth and not JWT in my case but the same approach applies to both.

The approach is to create an Access Token, that is not a Session ID but is attached to a session, and to store that value on the the client side accessible from JavaScript (e.g. JWT cookie, localStorage).

Often the Access Token is rotated in the session and includes an expiry time after which it is no longer valid. This can be anywhere from 5 minutes to a few hours. This makes it less valuable if someone somehow does manage to steal it using XSS, because it will eventually expire (unlike a session, which stays valid as long as it's actively being used).

You can the Access Token to allow some operations (e.g. identify the user, access to some read-only data) but not others. For example: You can still require a session token stored in an HTTP only cookie for POST requests (to modify data) or to read sensitive data (like billing or address info).

If you think it's worth the hassle I guess depends on what you are doing on your site and if you think it's worth the benefit and hassle over just storing the session in a JavaScript cookie. :-)

I've avoided JavaScript accessible cookies in next-auth to try and provide a best practice example, but a large number of major production sites just have sessions accessible in JavaScript because it's such a hassle and their risk/exposure is low.

[iaincollins]

Note: I'm leaving this ticket open till I've had a chance to look at the headers and see if there are some additional sensible defaults we could set. Am especially interested in node libraries for Express that provide some hardening by setting these automagically.

[dav-is]

Here’s something I wrote explaining the best way to handing auth tokens with SSR and an external API: https://spectrum.chat/thread/91bdb515-11b8-4d39-bd9a-925e16395cb7