ref –
- https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work
- https://medium.com/swlh/how-to-use-cookies-to-persist-state-in-nextjs-934bed5e6da5
How to Use Cookies to Persist State (User) in NextJS
With LocalStorage
There are a number of ways to persist users in a React or Single Page Application.
A lot of times, devs generally use localStorage to store user data and load the data from there when required.
While this approach works, it’s not the most effective way as it leaves users vulnerable to attacks.
Using cookies is a little safer although it’s still not the safest option.
Personally, I prefer:
- using cookies
- JWT’s(JSON Web tokens) with expiry to persist user session
- force a user to re-login when their session expires.
Using JWT’s is out of the scope of this article, we’ll only talk about cookies.
Getting started using cookies in React/NextJS
To use cookies in NextJS, we need to install 2 packages. For this tutorial, we’ll be using cookie and react-cookie. React-cookie allows us set the cookie from the client side while the cookie package lets us access the set cookie from the server-side. Install both packages by running
|
1 |
npm install react-cookie cookie |
Setting a cookie
With both packages installed, It’s time to set a cookie.
Usually, we set a cookie for a user once they’ve successfully signed in or signed up to our application. To set a cookie on Sign in, follow the example below.
Session Token
The session token, also known as a sessionID, is an encrypted, unique string that identifies the specific session instance. If the session token is known to a protected resource such as an application, the application can access the session and all user information contained in it.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
import cookie from "cookie"; import jwt from "jsonwebtoken"; const secret = "my-secret"; export function setSession(res, session) { const token = jwt.sign(session, secret); const cookieValue = cookie.serialize("session", token, { httpOnly: true, secure: process.env.NODE_ENV === "production", maxAge: 60 * 60 * 24 * 7, // 1 week sameSite: "strict", path: "/", }); res.setHeader("Set-Cookie", cookieValue); } export function getSession(req) { const cookies = cookie.parse(req.headers.cookie || ""); const token = cookies.session; if (!token) return null; try { return jwt.verify(token, secret); } catch (err) { return null; } } export function destroySession(res) { res.setHeader( "Set-Cookie", cookie.serialize("session", "", { httpOnly: true, secure: process.env.NODE_ENV === "production", expires: new Date(0), sameSite: "strict", path: "/", }) ); } |
sameSite
|
1 |
res.setHeader("Set-Cookie", `session=${sessionId}; Path=/; Max-Age=600; SameSite=Strict; HttpOnly`); |
The sameSite feature merely indicates whether a cookie can be retrieved through a different website with a different origin. Ideally, this should be accurate as it offers just one layer of defense against cross-site attacks.
CSRF tokens
A CSRF token is a secure random token (e.g., synchronizer token or challenge token) that is used to prevent CSRF attacks. The token needs to be unique per user session and should be of large random value to make it difficult to guess. A CSRF secure application assigns a unique CSRF token for every user session.
In a NEXT JS project, a session generates a unique session token, as well as a csrf token.
Say we sign in, and it uses CredentialsProvider. We need to evaluate it, and the credentials object has all the data:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
const handler = NextAuth({ providers: [ CredentialsProvider({ id: "credentials", name: "Credentials", async authorize(credentials) { await connect(); try { // if credential is ok, then we use code to log in const user = await User.findOne({email: credentials.email}); if (user) { return user; } } catch (err) { throw new Error(err); } }, }), ], }); |
Credential object looks like this in the code:
And in the browser, these values are stored in the browser cookie:
Cross-Site Request Forgery (CSRF) in simple words
Assume you are currently logged into your online banking at www.mybank.com
Assume a money transfer from mybank.com will result in a request of (conceptually) the form http://www.mybank.com/transfer?to=
You visit www.cute-cat-pictures.org, not knowing that it is a malicious site.
If the owner of that site knows the form of the above request (easy!) and correctly guesses you are logged into mybank.com (requires some luck!), they could include on their page a request like http://www.mybank.com/transfer?to=123456;amount=10000 (where 123456 is the number of their Cayman Islands account and 10000 is an amount that you previously thought you were glad to possess).
You retrieved that www.cute-cat-pictures.org page, so your browser will make that request.
Your bank cannot recognize this origin of the request: Your web browser will send the request along with your www.mybank.com cookie and it will look perfectly legitimate. There goes your money!
This is the world without CSRF tokens.
Now for the better one with CSRF tokens
The transfer request is extended with a third argument: http://www.mybank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795028841971.
That token is a huge, impossible-to-guess random number that mybank.com will include on their own web page when they serve it to you. It is different each time they serve any page to anybody.
The attacker is not able to guess the token, is not able to convince your web browser to surrender it (if the browser works correctly…), and so the attacker will not be able to create a valid request, because requests with the wrong token (or no token) will be refused by www.mybank.com.
Result: You keep your 10000 monetary units.