Forem: Guy Dumais

How to deploy a strict Content Security Policy (CSP) with Next.js

Guy Dumais — Sat, 11 Sep 2021 13:05:07 +0000

Based on the most comprehensive study to date from Google, 95% of real-world Content Security Policy (CSP) deployments are bypassed and 99.34% of hosts with CSP use policies that offer no benefit against XSS.

This is why Google suggests that the model of designating trust by specifying URL whitelists from which scripts can execute should be replaced with an approach based on nonces and hashes, already defined by the CSP specification and available in major browser implementations. Hence the name strict CSP.

In the context of a Single Page App (SPA) such as the Next.js React framework, we need to use a Hashed-based CSP in order to properly integrate a strict CSP which will offer real protection against CSS attacks.

Depending on the complexity of your application, the integration of a hash-based Content Security Policy could be trivial and require a lot of code manipulation. That’s why I’ve come to build a package on NPM specifically designed for Next.js to allow developers to integrate strict CSP in a snap with just a few lines of code.

next-strict-csp

next-strict-csp is a hash-based Strict Content Security Policy generator for Next.js that is easily integrated in the _document.tsx file of your Next.js application. Once in production, it will automatically inject the hashes into the content security policy meta tag and protect against XSS once deployed and cached on CDN.

Here is an example of _document.tsx with basic integration of next-strict-csp:

...

// Next.js libraries
import Document, { Html, Head, Main, NextScript } from 'next/document'

// Next Strict Content Security Policy
import { NextStrictCSP } from 'next-strict-csp'

...

// Enable Head Strict CSP in production mode only
const HeadCSP = process.env.NODE_ENV === 'production' ? NextStrictCSP : Head

...

// Document component
class MyDoc extends Document {

  render() {
    return (
      <Html>
        <HeadCSP>
          { process.env.NODE_ENV === 'production' && 
          <meta httpEquiv="Content-Security-Policy" />
          }

          ...

        </HeadCSP>
        <body>

          ...

          <Main />
          <NextScript />

          ...

        </body>
      </Html>
    )
  }

}

Once put live in production, you'll get a content security policy meta tag that looks like this:
<meta http-equiv="Content-Security-Policy" content="script-src 'strict-dynamic' 'sha256-XOzjewwkvGMLaoj+oYCiOZ3kRwb6RT1Ph6vn4qL+XI0=' 'unsafe-inline' http: https:;" slug="/">

With a strict CSP, you need to hash your inline scripts as well. This could be easily achieved with next-strict-csp by integrating your inline scripts in an array like this in _document.tsx:

...

// Next.js libraries
import Document, { Html, Head, Main, NextScript } from 'next/document'

// Next Strict Content Security Policy
import { NextStrictCSP } from 'next-strict-csp'

...

// Cloudflare Insights Script (Optional)
const cloudflareJs = `var s = document.createElement('script')
s.src = 'https://static.cloudflareinsights.com/beacon.min.js'
s.setAttribute('data-cf-beacon', '{"token": "YOUR CLOUDFLARE WEB ANALYTICS TOKEN STRING"}')
document.body.appendChild(s)`

// Google Tag Manager Script (Optional)
const GTMJs = `(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','YOUR GOOGLE TAG MANAGER ID STRING');`

// Next Strict CSP
// Inline scripts to hash  (Optional)
NextStrictCSP.inlineJs = [
  cloudflareJs,
  GTMJs
]

...

// Enable Head Strict CSP in production mode only
const HeadCSP = process.env.NODE_ENV === 'production' ? NextStrictCSP : Head

...

// Document component
class MyDoc extends Document {

  render() {
    return (
      <Html>
        <HeadCSP>
          { process.env.NODE_ENV === 'production' && 
          <meta httpEquiv="Content-Security-Policy" />
          }

          ...

          {/* Google Tag Manager */}
          { process.env.NODE_ENV === 'production' && 
          <script 
            dangerouslySetInnerHTML={{
                __html: GTMJs
            }}
          />
          }
          {/* End Google Tag Manager */}

        </HeadCSP>
        <body>
          { process.env.NODE_ENV === 'production' && 
          <noscript
            dangerouslySetInnerHTML={{
                __html: `<iframe src="https://www.googletagmanager.com/ns.html?id=YOUR GOOGLE TAG MANAGER ID STRING" height="0" width="0" style="display:none;visibility:hidden"></iframe>`,
            }}
          />
          }

          ...

          <Main />
          <NextScript />
          {/* Cloudflare Web Analytics */}
          {/*<script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon={`{"token": "YOUR CLOUDFLARE WEB ANALYTICS TOKEN STRING"}`}></script>*/}
          {process.env.NODE_ENV === 'production' && 
          <script dangerouslySetInnerHTML={{
            __html: cloudflareJs
          }} />
          }
          {/* End Cloudflare Web Analytics */}

          ...

        </body>
      </Html>
    )
  }

}

Once live, your inline scripts hashes will be injected into the content security policy meta tag like this:
<meta http-equiv="Content-Security-Policy" content="script-src 'strict-dynamic' 'sha256-XOzjewwkvGMLaoj+oYCiOZ3kRwb6RT1Ph6vn4qL+XI0=' 'sha256-QSxH3dqIUPdeBvyxSZSuIbZfgtCo/yuqnzU+5gtq9Ak=' 'sha256-7V8IQTE3j8PL2rD62J9XsmUhchGnkkyNIQfwoYVK04I=' 'unsafe-inline' http: https:;" slug="/">

Last word

Hope you enjoyed next-strict-csp and don't hesitate to leave a comment to let me know what you think about it.

Thanks for reading, see you!

Next.js: The Ultimate Cheat Sheet To Page Rendering

Guy Dumais — Mon, 19 Jul 2021 21:51:19 +0000

Next.js uses 4 rendering strategies to build, deliver and render a React Single Page App (SPA):

1. Static-Site Generation (SSG)
2. Server-Side Rendering (SSR)
3. Incremental Static Regeneration (ISR)
4. Client-Side Rendering (CSR)

This is the easiest and most complete cheat sheet to quickly understand how Next.js page rendering strategies works. Moreover, this unique cheat sheet clearly reveals how each strategy influences the Core Web Vitals signals: TTFB, FP, FCP, LCP, TBT and TTI.

Detailed explanations are also included to help you choose the right page rendering strategy for all use cases and thus create speedy Web applications that Google and visitors love.

P.S.: Thanks in advance for including this cheat sheet in your blog articles and mentioning the author with a link back to this cheat sheet like this: Next.js: The Ultimate Cheat Sheet To Page Rendering.

Enjoy!

How to use

The 4 page rendering strategies are identified with their respective acronym (SSG, SSR, ISR and CSR) and laid out in columns besides each other in the middle of the infographic.

Completely on the left side of these 4 columns you’ll find the 6 steps involved during the processing flow from the build step on the server side up to the client-side rendering.

Completely on the right side of these 4 columns you’ll find where each step happens in the processing flow which is either server side or client side.

For each strategy column you’ll see where and when a build action (page generation) is executed in the step. You’ll also see the generated content flow (HTML - React/CSS/JS/Data) during each single step.

Core Web Vitals

The Core Web Vitals (CWV), parts of the new page experience ranking factor from Google, are identified using 3 distinctive background colors, each related to the performance impact on the CWV.

A red color means POOR performance results, an orange color means GOOD performance while a green color means the BEST performance.

Live Demo

You’ll find a live demo with example source code on Github for testing the performance of each page rendering strategies discussed in the cheat sheet:
https://next-page-rendering.vercel.app/

Static-Site Generation (SSG)

Static-Site Generation (SSG) is the default strategy offered by Next.js to generate web pages. Next.js recommends this strategy to get the best performance results as static content is distributed faster using CDNs which are closer to your visitors and thus leading to a faster Time to First Byte (TTFB).

Steps description

STEP 1: Next.js generates a Single Page App in an .html file along with the .css and .js on the server. This step called pre-rendering is done only once at build time when you run the next build command. That is usually done when you deploy your application. This is during this step that all the page coding (HTML) is generated including the React code, CSS, JavaScript and optionally the data if the page is using any data fetching method such as getStaticProps() or getStaticPaths().

STEP 2: The client requests the Single Page App from the CDN.

STEP 3: The client downloads the Single Page App from the CDN.

STEP 4: The client parses and renders the Single Page App into the browser. This is where the 3 Core Web Vitals signals (First Paint, First Contentful Paint and Largest Contentful Paint) are fired. Because the HTML of the page has been pre-rendered on the server side, the client browser just has to load and render it as is. And because the page is coded in a way that allows the browser to render it with minimum JavaScript code, render-blocking is reduced to its minimum leading to good performance results.

STEP 5: The React (JavaScript) code is run to (re)Hydrate the page. Even though the page has been pre-built, this extra step is required to allow React to attach or activate the JavaScript events to its Virtual DOM and make the page interactive. Because JavaScript is run at this point, Total Blocking Time is affected by this extra step. Also, because the browser has to wait for the hydration process to complete, Time To Interactive is also affected.

Here is the complete Typescript code of a web page that uses Next.js' Static-Site Generation strategy (SSG):

// Next.js libraries
import Head from 'next/head'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function StaticSideGeneration({ jsonData }) {
  return (
    <>
      <Head>
        <title>Static-Site Generation (SSG) • Guy Dumais</title>
        <meta name="description" content="Example page using Static-Site Generation (SSG) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Static-Site Generation (SSG)</h1>
      <p>Data fetched at build-time on the server-side before sending to the client.</p>
      <ul>
      {
        jsonData.data.map((e) => (
          <li key={e.id}>{e.email}</li>
        ))
      }
      </ul>
    </>
  )
}

// This function gets called at build time on server-side.
// It won't be called on client-side, so you can even do
// direct database queries.
export async function getStaticProps() {
  const res = await fetch('https://reqres.in/api/users?page=2')
  const jsonData = await res.json()

  return {
    props: {
      jsonData, // will be passed to the page component as props
    },
  }
}

Server Side Rendering (SSR)

Server Side Rendering (SSR) is the second strategy offered by Next.js to generate web pages. Next.js recommends to avoid using this strategy as much as possible to get the best performance results as the static content is built (pre-rendered) and distributed per-request only. Because of the extra time required by the build process, the Time to First Byte (TTFB) signal is increased and leads to poor results.

Steps description

STEP 1: Next.js does not generate (pre-render) any page.

STEP 2: The client requests the Single Page App from the server. Next.js generates (pre-render) a Single Page App in an .html file along with the .css and .js on the server. This is during this step that all the page coding (HTML) is generated including the React code, CSS, JavaScript and optionally the data if the page is using the getServerSideProps() data fetching method.

STEP 3: The client downloads the Single Page App from the server.

STEP 4: Same as STEP 4 in SSG.

STEP 5: Same as STEP 5 in SSG.

Here is the complete Typescript code of a web page that uses Next.js' Server Side Rendering strategy (SSR):

// Next.js libraries
import Head from 'next/head'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function ServerSideRendering({ jsonData }) {
  return (
    <>
      <Head>
        <title>Server-Side Rendering (SSR) • Guy Dumais</title>
        <meta name="description" content="Example page using Server-Side Rendering (SSR) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Server-Side Rendering (SSR)</h1>
      <p>Data fetched on the server-side at <b>each</b> request before sending to the client.</p>
      <ul>
      {
        jsonData.data.map((e) => (
          <li key={e.id}>{e.email}</li>
        ))
      }
      </ul>
    </>
  )
}

export async function getServerSideProps() {
  const res = await fetch('https://reqres.in/api/users?page=2')
  const jsonData = await res.json()

  return {
    props: {
      jsonData, // will be passed to the page component as props
    },
  }
}

Incremental Static Regeneration (ISR)

Incremental Static Regeneration (ISR) is the third strategy offered by Next.js to generate web pages. It is the same as Static Site Generation except that content can be rebuilt when the page is updated.

Steps description

STEP 1: Same as STEP 1 in SSG.

STEP 2: The client requests the Single Page App from the CDN. Also, if the page is using the data fetching method getStaticProps() combined with the revalidate option, then the page is regenerated if the data returned from the fetching results has been updated. Next.js recommends using this method for a huge site having over 1,000 pages. Because pre-rendering each page takes time, using this incremental method will pre-render on the first request and when the page content is updated only.

STEP 3: Same as STEP 3 in SSG.

STEP 4: Same as STEP 4 in SSG.

STEP 5: Same as STEP 5 in SSG.

Here is the complete Typescript code of a web page that uses Next.js' Incremental Static Regeneration strategy (ISR):

// Next.js libraries
import Head from 'next/head'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function IncrementalStaticGeneration({ jsonData }) {
  return (
    <>
      <Head>
        <title>Incremental Static Regeneration (ISR) • Guy Dumais</title>
        <meta name="description" content="Example page using Incremental Static Regeneration (ISR) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Incremental Static Regeneration (ISR)</h1>
      <p>Data fetched at build-time on the server-side and rebuilt when data updated.</p>
      <ul>
      {
        jsonData.data.map((e) => (
        <li key={e.id}>{e.email}</li>
      ))
      }
      </ul>
    </>
  )
}

// This function gets called at build time on server-side.
// It may be called again, on a serverless function, if
// revalidation is enabled and a new request comes in
export async function getStaticProps() {
  const res = await fetch('https://reqres.in/api/users?page=2')
  const jsonData = await res.json()

  return {
    props: {
      jsonData, // will be passed to the page component as props
    },

    // Next.js will attempt to re-generate the page:
    // - When a request comes in
    // - At most once every second
    revalidate: 100, // In seconds
  }
}

Client Side Rendering (CSR)

Client Side Rendering (CSR) is the fourth strategy offered by Next.js to generate web pages. It is the same as Static Site Generation except that parts of the content can be built on the client side.

Steps description

STEP 1: Same as STEP 1 in SSG except that the content (data) is not pre-rendered nor included in the static bunch. Which results in a smaller file size thus leading to shorter download time.

STEP 2: Same as STEP 2 in SSG but without content (data).

STEP 3: Same as STEP 3 in SSG but without content (data).

STEP 4: Same as STEP 4 in SSG.

STEP 5: Same as STEP 5 in SSG but without content (data).

STEP 6: The client fetches the content (data) and React updates the UI. This method is useful, for example, when you want to show up a skeleton page with static content and then progressively inject the data in a page requiring a long wait time for data fetching.

// React
import { useEffect, useState } from 'react'

// Next.js
import Head from 'next/head'
import Link from 'next/link'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function ClientSideRendered() {

  const [state, setState] = useState([] as any)

  const getData = async () => {
    const res = await fetch('https://reqres.in/api/users?page=2')
    const jsonData = await res.json()
    setState(jsonData)
  }

  useEffect(() => {
    getData()
  }, [])

  return (
    <>
      <Head>
        <title>Client-Side Rendering (CSR) • Guy Dumais</title>
        <meta name="description" content="Example page using Client-Side Rendering (CSR) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Client-Side Rendering (CSR)</h1>
      <p>Data fetched on the client-side only.</p>
      <ul>
      {
        state.data?.map((e) => (
          <li key={e.id}>{e.email}</li>
        ))
      }
      </ul>
    </>
  )

}

Why I choose Next.js and Sanity for my new blog

Guy Dumais — Sat, 03 Jul 2021 12:50:08 +0000

The big move...

One of the main reason I've always love doing this job is the fact that technologies are always evolving for the better. They are constantly improving ways to do more with less. And it still happening nowadays with the latest Jamstack technologies such as React.js, Next.js and Sanity to name a few. I see it as a kind of technology revolution.

As a Software Engineer, I've got to keep up to date with the latest technologies and because no Software Engineer knows everything, the more you know, the better your web applications will be, and the better the user experience will be as well. And this is the main reason why I've decided to upgrade my knowledge and move my personal blog into the Jamstack world to experience the REAL experience on the ground.

And this is also the reason I've written this article in hope that it can help anyone's willing to move into the Jamstack world, also looking for choosing the right technologies from the start to build and scale your online business without having to restart from scratch as technology evolve.

Overcoming challenges

Despite my huge IT background mixed with my latest web skills it was still difficult to get there. But I finally succeeded and the end results paid back. The proof is that I'm now having this blog which is entirely using the latest Jamstack technologies giving much better SEO results with Lighthouse scores over 90% on almost every single pages.

My first challenge has been to learn React developed by Facebook which required a brand new way to think when developing. In the end, you have to think in React. Briefly, React is a Javascript library that help you build dynamic user interfaces.

The main approach to adopt while developing in React is to split your application elements in components. It was a bit confusing at start, specially for an object oriented programmer like me, but once you catch the idea behind the library, the end result is a much better code which is much easier to maintain while the application is growing. This is a huge productivity boost for a developer.

My second challenge has been to find a framework to build and host my website which is now a progressive web application (PWA). There are many solutions available out there each offering different advantages depending on your needs.

After giving a try to Gatsby, which is a great framework as well, I've switched to Next.js because it allows me to do more with less in the end.

My third challenge has been to find a way to host and manage my blog content. Since React is used to only manage the UI (frontend) part of a Web application, you need another technology to host and manage your content (backend). That's what I call the CMS Stack or the Content Stack.

The CMS Stack could be WordPress, Magento, Joomla or whatever content manager you prefer. The beauty with Jamstack is that you could still use any content management system (CMS) behind the scene and use React as the UI to pull and push this content to your visitors. One of the main advantages of the stack approach is that you could change your CMS without having to rebuild your UI from scratch.

After lot of searching and experimentations, I've finally opted to use Sanity as my CMS, explained in more details further down in this article, for its brand new powerful and flexible structured content approach using portable text, which, in my humble opinion, is going to get adopted widely in the future.

Next.js

In short, Next.js is a framework to generate modern websites using React. More over, it allows you to run serverless functions which make it very useful to quickly run some backend business logic such as authentication, payments to name only few.

I got a crush for the production part when time has come to publish my work online in just a few clicks with their Vercel platform which offer a generous free offer for hosting your web application.

For sure, I'll be posting more about how to do things the right way with Next.js. Once you understand the way Next.js is doing things behind the scene, you'll do amazing things with few efforts.

Sanity

Sanity.io is a content management system (CMS) that is framework independent. What I mean by that is that I can connect other frontends to my blog content (texts, images, etc.) that no more rely on a specific CMS cause it's saved in JSON format which can be consumed by any API compatible UI framework such as Next.js, Gatsby, Vue.js.

So now, I can switch my frontend framework without having to rebuild my content. Also, I can switch my content to a CDN or any other server that can host and deliver JSON files without having to rebuild my frontend. For exemple, I could move my JSON content on Google Drive.

Sanity.io lets me work with structured content. That means I can add more content types. Who knows, I might add my portfolio, maybe a podcast, some products that I need to market, or my personal music creations.

Also, Sanity comes with a Studio Editor which is fully customizable to make it work the way you want for your specific needs. Again, I'll be posting more about how Sanity and the ways to do things correctly.

Tailwind

I've never been a big fan of css frameworks because of the extra weight added to each page load and the learning curve. The first time I looked at Tailwind I liked the approach which consist of adding classes a bit like Bootstrap. But I didn't liked the learning curve and the extra weight of the version 1 framework.

But I've changed my mind since I looked and tried the version 2, now we're talking about something interesting. Since version 2, only the styles used in the webpage will be loaded. Which means a smaller footprint for the css.

The final word

Who could have said a few years ago that Javascript, which was used to do basic calculations and animations in web pages, would become one of the main language used for building web applications. In my humble opinion, with the growing popularity of React, Javascript is going to become the most popular programming language on the web.

The old static web page composed mainly of html and css, dynamically generated server-side using a monolithic server architecture is dying . Nowadays we're talking about client-side web applications powered worldwide on hundreds of CDN servers. Which make your web applications more reliable, cheaper to host but above all, much more secure.

In my humble opinion, the best approach to use is to create a minimum viable product (MVP) like this blog, using the LEAN method. That is to say that even if it does not contain all the features that I would like to have at the moment, I have integrated the minimum elements such as Google Analytics, Opengraph, metadata and responsive images, to allow me to create content on a scalable platform adapted to current technological requirements.

But above all, the main goal is to create the best web experience as possible for the mobile user which now consume our content using any kind of devices from anywhere.

Over time, I'll be adding new features such as Authentication for accessing exclusive content, newsletter subscription and Internationalization (i18n) which I've learned recently and took me a while to mastered, specially the English/French translations with React routing that is not ready out-of-the-box but mature enough to be put live in production.

Now that I have explored and found the right frameworks, let's build great content to make this blog my own special place on the internet.

Keep coming back, my next goal is to integrate a Newsletter...

See You!