DEV Community: Adel

CSRF Protection in Next.js

Adel — Mon, 07 Mar 2022 22:53:29 +0000

Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated.

It ensures the authenticity of your requests.

We will use a popular npm package to handle CSRF called csurf.

Because csurf is express middleware, and there is no easy way to include express middlewares in next.js applications we have two options.

1- Create custom express server and use the middleware, check this link
2- Connect express middleware, we will follow this method, more details in next.js docs

we will create new file /src/csrf.js

import csurf from 'csurf'

// Helper method to wait for a middleware to execute before continuing
// And to throw an error when an error happens in a middleware
export function csrf(req, res) {
    return new Promise((resolve, reject) => {
        csurf({ cookie: true })(req, res, (result) => {
            if (result instanceof Error) {
                return reject(result)
            }
            return resolve(result)
        })
    })
}

export default csrf

Now we have two steps to implement this,

1- Make sure the API is protected by CSRF token.

Lets take the default API route that comes with initial next.js project "hello.js", to include the middleware we need to do the following

import csrf from "../../src/csrf";
export default async function handler(req, res) {
  await csrf(req, res);
  res.status(200).json({ name: 'John Doe' })
}

This way we are protecting this route with CSRF token

2- Expose this token to the react page so it can be sent with the requests.

To get the token

export async function getServerSideProps(context) {
    const { req, res } = context
    await csrf(req, res)
    return {
        props: { csrfToken: req.csrfToken() },
    }
}

Now on the next API call to hello.js we need to include the token in the header, here I used axios but you can use fetch as well

axios.post('http://localhost:3000/api/hello', {}, {headers:{'CSRF-Token': csrfToken}})
    .then(res=>console.log({data: res.data}))

And that's it, Now you are protected against CSRF attacks

Note that you can add more options to your cookie like make it HttpOnly and change the key name, check the library docs for more details.

Browser Storage APIs

Adel — Sun, 30 Jan 2022 22:04:46 +0000

1- Cookies

Cookies are small pieces of text data stored in the browser mainly used for authentication, tracking and personalization.

Cookies can be read and set by browser and server with certain rules, hold 4069 bytes of data.

For more details I have an article “Cookies: simple and comprehensive guide”

To set a cookie using javascript

document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC";

2- Web Storage

Similar to cookies, pieces of text data stored in the browser. It can hold up to 5MB and can be read and set only by the browser.

It offers simpler APIs than cookies and all Web Storage calls are synchronous.

The two mechanisms within Web Storage are as follows:

Local Storage

No expiration date.
SessionStorage

data is stored until the tab is closed.

Code Example

localStorage.setItem('myCat', 'Tom');
const cat = localStorage.getItem('myCat');
localStorage.removeItem('myCat');
localStorage.clear();

3- IndexedDB

A Transactional NoSQL database system built in the browser. It can be used synchronously and asynchronously.

If you have big amount of data or files that needs to be stored in the browser, IndexedDB is a good option.

While it includes more features than traditional Web Storage API, using IndexedDB is also more complex, for that there are open source libraries to simplify it like localForage which wraps IndexedDB API and makes it as simple as using Web Storage API

4- Cache

Used mainly to optimize the performance of the website by storing its files to not be downloaded again when you open the same website again.

You can cache any response whether it’s HTML, Javascript, CSS, image, font or even API response.

The storage allowed for cache storage is different per browser, for example Chrome allow to take 80% of available disk space.

What is Beacon request

Adel — Thu, 27 Jan 2022 22:27:03 +0000

navigator.sendBeacon() method asynchronously sends an HTTP POST request in reliable way, it's mostly used to send analytics.

it returns true if the user agent successfully queued the data for transfer. Otherwise, it returns false.

Unlike traditional HTTP requests, sendBeacon will always reach to the server even if you unload or exit the page in the middle of the request.

Example

document.addEventListener('visibilitychange', function logData() {
  if (document.visibilityState === 'hidden') {
    navigator.sendBeacon('/log', analyticsData);
  }
});

Cookies: simple and comprehensive guide

Adel — Sun, 23 Jan 2022 00:17:41 +0000

Cookies are small pieces of text data stored in the browser mainly used for authentication, tracking and personalization.

Limits

Typically, the following are allowed:
300 cookies in total
4096 bytes per cookie
20 cookies per domain
81920 bytes per domain
** Given 20 cookies of max size 4096 = 81920 bytes.

How to create a cookie?

Javascript:

document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC";

HTTP response:

Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

How to read a cookie?

Javascript: Note that javascript will not have access to httponly cookies.

let x = document.cookie; // returns cookie1=value; cookie2=value;

HTTP request: your browser will send the cookies to the associated site in eligible requests in the http headers, so it's easy read them from service side.

How to delete a cookie?

just set the same cookie with passing "expires" as a past date.

Attributes:

Secure: The cookie will be sent only over https.
HttpOnly: Can't be accessed from client side.
Domain: the cookie will be sent if the domain matches or if it is a subdomain, then the path attribute will be checked next.
Path: if the path attribute was set to the web server root /, then the application cookies will be sent to every application within the same domain If set to specific path like "/blog", then it will be sent only to the requests that matches the path like "/blog/hello".
Expires: To specify when the cookie will die, this time is relative to the client not the server.
Max-Age: After how many seconds the cookie will expire, not supported by all browsers.
SameSite: To control sending cookies along with cross-site requests and take three values:
- Strict: Sent only to first-party.
- Lax: Default in most browsers, same as Strict except that cookies are sent when the user navigates to the cookie's origin site.
- None: Sent cross-site.

Prefixes:

__Host- : the cookie will be rejected if not Secure with no Domain and Path = "/".
__Secure- : will be rejected if not Secure.

Types:

First-party Cookies:
Set by the website visited by the user through HTTP headers.
Third-party Cookies:
Set by other domains, examples: ads, iframes, fonts, images from other domains.
Starting in chrome v80 cookies are restricted to first party, default value for samesite attribute if not set is Lax,
If you need 3rd party you need to explicitly mark it as samesite=none and sercure=true.
Persistent Cookies:
Deleted at a date specified by the Expires attribute, or after a period of time specified by the Max-Age attribute.
Non-persistent Cookies:
If expires attribute is empty, it will be deleted when you close your browser.
Zombie Cookies:
Extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies.
Flash Cookies:
No longer exists, local shared object used by Adobe Flash.

Legal:

All regulations require:

Notify user that you are using cookies.
Allowing users to opt out of receiving some or all cookies.
Allowing users to use the bulk of your service without receiving cookies.

Further reads:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
https://github.com/samyk/evercookie

Simple way to do device fingerprinting

Adel — Sat, 08 Jan 2022 20:21:25 +0000

Device fingerprint is a unique identifier for a specific device the most common uses for it are fraud detection and user validation.

There is no clear way to get this unique identifier instead, we will try to generate a string out of some information collected from the user.

Fingerprinting can be on the client-side (browser) or on the backend, we will do the backend way because it doesn't limit us by the user device or the features enabled on it.

You can use a lot of parameters to generate this identifier, in my case I'm trying to detect if the user is trying to log in from a different device or browser to the same account, for this simple case I will use a combination of IP address, user agent and params(credentials + CSRF token)

You can add more parameters to this combination like cookies or other headers.

I used here md5 as a hashing algorithm to generate the fingerprint but you can use a different one.

const md5 = require('crypto-js/md5')
const requestIp = require('request-ip');

const ip = requestIp.getClientIp(req);
const useragent = req.headers['user-agent'];
const params = request.body;
const fingerprint = md5(ip + useragent + JSON.stringify(params)).toString();

5 ways to use microforntends

Adel — Sat, 08 Jan 2022 13:34:10 +0000

What is microfrontend:

In short, it's a way to a way to apply the microservice principles to frontend applications, this will give multiple benefits like Autonomous teams, Easier maintenance, independent deployments, and flexible tech choices.

The best use for microfrontend architecture is when you have a large-scale application and a large team working on it and you want to divide to conquer, otherwise adopting microfrontend architecture will be overkill.

1. iFrames
The old good iframe tag, you can use anywhere on your page, you need to make sure this header is enabled on the page you want to include as an iframe
X-Frame-Options: ALLOW-FROM https://example.com

You can pass data from the parent page to the iframe in two ways:

Url params
Postmessage

2. Javascript bundles
Include any javascript file written in any framework to your page at runtime, and make sure that this file will render itself in a specific div you will create in a certain place in your original app
You can include CSS files in the same way, or include manifest.json file which reference all your JS and CSS files (if you have multiple javascript and CSS files) and it will load all needed files automatically

3. Zones
Feature in Next.js lets you reference another project as a page in the main app using redirects, if you are not using Next.js you can achieve that using Nginx as well.
Since the main app and all the zones are on the same domain, they will share the cookies so you can do authentication on the main app and the other apps can read the auth cookie

4. Module federations
A new feature in webpack 5, allows you to export one of your components and use it in another app and import it like any other component in the app, any update on the federated component will reflect all consumers at runtime

5. Other dedicated frameworks
There are number of frameworks designed to build microfrontends like
https://bit.dev/
https://single-spa.js.org/

Demo

I created a small demo used Zones and Module federations
I this demo there is 2 Zones, Home and Products, and I exported the top menu bar as federated module from Home app and used it in both Home and Products
Also using next-auth library I created a simple auth and since and it's shared between two zones

Demos
https://mfe-shop-home.vercel.app/
https://mfe-shop-products.vercel.app/products

Code
https://github.com/adelhamad/micro-frontend-shop

Further reads
https://www.facebook.com/notes/10158791368532200/
https://dev.to/luistak/cross-micro-frontends-communication-30m3
https://micro-frontends.org
https://martinfowler.com/articles/micro-frontends.html
https://indepth.dev/posts/1477/taking-micro-frontends-to-the-next-level#third-party-micro-frontends

BFF - Backend for Frontend Design Pattern with Next.js

Adel — Tue, 26 Oct 2021 16:24:50 +0000

Intro

These days microservice architecture becoming more and more popular, and if you worked on a project that adopt this architecture then as a frontend developer you probably faced one of the following scenarios:

You support multiple platforms ( web, mobile app, smartwatch…. ) and each one has a specific need of data.
Calling APIs from multiple services to build one user interface.
Manipulate, mix and match the responses of multiple API calls to reach the desired shape of data.
Receive unnecessary data from API that you don't need at all.
Receiving the same piece of info from different services with the different data types, for example one service could send the date as epoch and other one might send it as a Linux timestamp.
Finding yourself writing complex computations or maybe business logic in the frontend.

As your codebase grows and becomes more complex, it becomes hard to keep organized, and by the time you might find your codebase out of control and of course complexity where the bugs hide.

Typically the frontend code should be very simple, straight forward and easy to read, and we should avoid doing complex computations in the UI layer especially while rendering, otherwise you will be using a lot more of browser resources which will lead to bad performance .

General Purpose API

Generic APIs contain unnecessary data that is sometimes of no use for consumer applications This might be critical sometimes especially when sometimes we need to deliver as small response as possible to some frontends like smartwatches.

Each one of these frontends may have specific needs about the data delivered to it from the backend. And since all of them calling the same API, the backend developer will try to spit every piece of data available to satisfy all frontends needs.

What Is BFF Design Pattern

This pattern was first described by Sam Newman.

By Implementing BFF we try to keep the frontend decoupled from the backend. The BFF should be tightly coupled with frontend, Because in the first place it existed to serve the frontend needs and Ideally it should be built by the frontend developer.

In most cases we should have one BFF for each frontend, then we can customize the BFF and fine-tune it according to that frontend needs.

In some cases we might share one BFF with multiple frontends if the requirements are very similar, for example one BFF for iOS and Android this way is adopted by SoundCloud for example, by doing this you will avoid a lot of duplicate code across BFFs.

One BFF per frontend

Sharing BFF for some frontends

Not an API gateway: you might think that the BFF is very similar to API gateway but it's not because the main reason for API gateway is to be a reverse proxy between the consumer and all other microservices not to customize the response according to this particular frontend needs. Also API gateway is the single entry point for anybody need to reach any backend service wheather the BFF is specific to one frontend.

BFF will hide a lot of complexities from the frontend which will make the app more resilient to new change.
Also you have the freedom the use any protocol you are most comfortable with like GraphQL, even if the other services use REST or SOAP.

Using BFF will also abstract the frontend related unit tests .

Note that the BFF pattern is not useful when you only support one frontend.

With Multiple Backend services

Lets say you need to build a user profile page for a social platform, and this platform is built with microservices architecture, then it will look something like this.

As you see here the web UI calls APIs from multiple services to build the profile page.
First needs to get the data about the user, and do another two or more calls to get the rest of the results based on the fetched username or user id. Note that the response could contain a lot of data that is not needed to build this UI, the latter calls can be called on parallel to be executed in less time, then you need to merge the responses and gather only the data you need to build this user profile page. It looks painful right? Imagine you have similar scenarios with much more complex UIs and much more services to consume data from, this is not very practical.

Instead it will be more efficient to call just one API and get only the data needed to build this page, and this is what needs to happen in the BFF layer.

In this way we abstracted all this complexity from the frontend, and the frontend role here is just to present the returned data.

I will do an example for the same problem later in this article.

API Versioning and A/B testing

Sometimes you maybe supporting different versions of the API for the same service, it's much easier to abstract this from the frontend and do it inside the BFF. This way the frontend will not be aware of the version it will just render the UI no matter what.

It can be useful as well when you want to run A/B testing campaign, for example you can return the version needed for specific users with the user object then let the BFF handle different API versions.

Nice Additions, Taking it further

Now after you added the BFF layer, there is a lot of cool things you can do specifically to that frontend.

Security: Because you are sending only what the frontend needs, you are hiding a lot of unnecessary or sensitive data that the attacker might use against you.
Caching: You can connect to redis for example directly and cache the API responses, then serve the results from the cache if available instead of calling the microservice.
Error Handling: multiple services can handle errors in different ways, in the BFF you can define a unified way to give the frontend a consistent response in case of any error happens.
Access Control
Logging
Web Sockets
etc …

Although I think it's better to keep it as simple as you can and stick to the main reason of building this BFF which is solving the problems of that specific frontend not solving general problems.

As the codebase grows, you might find yourself implementing general-purpose tiny services inside the BFF (sound cloud faced this issue) so try to keep the scope of the BFF as it's defined from the beginning.

With Next.js

By using Next.js you will get a few benefits out of the box

Fewer deployments: you don’t need to deploy your BFF separately because it will be integrated with Next.js by default.
Using the backend layer in Next.js, BFF will be tightly coupled to your frontend which is what we exactly need.
Sharing code like type definitions and utility functions between BFF and the frontend will be very easy.

For the sake of demonstrating how BFF work we will use Next.js API to simulate the microservices behavior, so we will have one file for each of the following:

Messaging service will include
- One endpoint to get all messages based on "read" filter, and it can take two values (true, false).
- One endpoint to get the latest message received (to get the last seen).
Notification service will include one endpoint to get all notifications based on "seen" filter and it can take two values (1,0).
Friends service will include one endpoint to get all pending friend requests.
BFF itself will consume APIs from all of those services.

First, we will see how the data will look like from each service.

Message object

    {
        "uid": "263f4178-39c6-4b41-ad5b-962a94682ceb",
        "text": "Morbi odio odio, elementum eu, interdum eu, tincidunt in, leo. Maecenas pulvinar lobortis est. Phasellus sit amet erat. Nulla tempus.",
        "created_at": "1634320826",
        "read": false
    }

Notification object

    {
        "uid": "ee7cd9df-2409-46af-9016-83a1b951f2fa",
        "text": "Vestibulum quam sapien, varius ut, blandit non, interdum in, ante.",
        "created_at": "1617738727000",
        "seen": 0
    }

Person object

    {
        "id": 1,
        "first_name": "Marillin",
        "last_name": "Pollicott",
        "birthdate": "4/20/2021",
        "email": "mpollicott0@wikispaces.com",
        "gender": "Male",
        "ip_address": "105.134.26.93",
        "address": "2132 Leroy Park",
        "created_at": "9/13/2021"
    }

Desired profile object

{
    "name": "John Doe",
    "birthdate": "2020-11-17T00:00:00.000Z",
    "address": "242 Vermont Parkway",
    "joined": "2021-08-27T00:00:00.000Z",
    "last_seen": "2021-10-15T18:00:26.000Z",
    "new_notifications": 61,
    "new_messages": 56,
    "new_friend_requests": 15
}

Notice the differences in data types for each service, like date, in message object it's a Linux timestamp in seconds and in notification service it's Linux timestamp in milliseconds while it's just simple date string in friends service and what we want actually is a simplified extended ISO format with the timezone set to zero UTC offset so it can be formatted in the frontend however we want. You can see also message service the Boolean represented as (true, false) and in notification service it's (1,0) you can spot other differences too if you look in details.

Also, notice the person object we have first and last name as different attributes, but in the frontend we show the combination of both.

So the main task of the BFF is to get data from different services, gather them and format them in the easiest form so the frontend will do the least effort to render these data. For that we defined a new interface (Profile).

interface Profile {
   name: string
   birthdate: Date
   address: string
   joined: Date
   last_seen: Date
   new_notifications: number
   new_messages: number
   new_friend_requests: number
}

In this interface we described the data we want and in which type to guarantee that the response returned to the frontend will be always correct.

You can check the code on this link
The demo on this link

One more cool thing with Next.js
If you are planning to integrate with some sort of caching mechanism like redis, next.js will make it much more easy and performant.

With server-side rendering in next.js you can just get the data from redis and just send the page ready to the frontend without the need to call an API from the frontend, the data will just be there in the fastest way possible.

TL;DR

BFF focuses on Creating a new backend per frontend that only serves the needs of that frontend.
BFF will call APIs from multiple services and form the minimal response required.
Frontend will get only what is needed to render the UI.

Further Reads

https://samnewman.io/patterns/architectural/bff
https://developers.soundcloud.com/blog/service-architecture-1
https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends