Tag: Response Header
Security Headers in Next.JS

Security Headers in Next.JS

To ensure your site is protecting its users. several security headers can be set to help prevent certain attacks against websites.

For Next.JS these are set in the next.config.js file. Typically I use the following config.

1/** @type {import('next').NextConfig} */
2const nextConfig = {
3  async headers() {
4    return [
5      {
6        source: '/:path*',
7        headers: [
8          {
9            key: 'X-Frame-Options',
10            value: 'SAMEORIGIN',
11          },
12          {
13            key: 'Content-Security-Policy',
14            value: "frame-ancestors 'none'",
15          },
16          {
17            key: 'Referrer-Policy',
18            value: 'same-origin',
19          },
20          {
21            key: 'Strict-Transport-Security',
22            value: 'max-age=15768000',
23          },
24          {
25            key: 'X-Content-Type-Options',
26            value: 'nosniff',
27          },
28          {
29            key: 'X-XSS-Protection',
30            value: '1; mode=block',
31          },
32        ],
33      },
34    ];
35  },
36};
37

38module.exports = nextConfig;
39

Content-Security-Policy

Setting frame-ancestors: none is similar to X-Frame-Options and will prevent a site loading in an ancestor frame, iframe. object or embed.

X-Frame-Options

Indicates whether a browser should be allowed to render a page in a frame, iframe, embed or object tag. By setting to SAMEORIGIN this ensures the site is only rendered in this way on itself and not on other sites.

Click-jacking attacks commonly use display other sites within themselves to fool a user as to what site they are on.

Referrer-Policy

Referrer Policy sets how much information is sent with the referrer header. By setting to same-orign, the referrer header is only sent on same origin requests.

Strict-Transport-Security

This header instructs the browser to only access the site over https. By setting the age it instructs the browser to remember this setting for the number of seconds given.

X-Content-Type-Options

Setting to nosniff will block a request if the destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type.

X-XSS-Protection

This is a non-standard header and isn't supported in any current browsers but has history support with Chrome and Edge.

The header instructs the browser how to handle any cross-site scripting attacks it detects on the page. Setting to 1; mode-block will prevent the page from rendering if an attack is detected.

Updating the response headers on your 404 Page in Sitecore

A few weeks ago I blogged about how to create a custom 404 Page in Sitecore. Following on from that, one thing you may notice in the response header of your 404 Page is the status code is 200 Ok, rather than 404 Page not found.

When Sitecore can't find a page what actually happens is a 302 redirect is issued to the page not found page, which as its an ordinary page will return a 200 Ok. Thankfully Google is actually quite good at detecting pages a being 404's even when they return the wrong status code, but it would be better if our sites issues the correct headers.

Method 1

The simplest solution is to create a view rendering with the following logic and place it somewhere on your page not found page. This will update the response headers with the correct values.

1@{
2      Response.TrySkipIisCustomErrors = true;
3      Response.StatusCode = 404;
4      Response.StatusDescription = "Page not found";
5}

However personally I don't think this a particularly neat solution. The contents of a view should really be left for what's going in a page rather than interfering with its headers, even if it does have access to the Response object.

Method 2

Rather than using a view my solution is to add some code to the httpRequestEnd pipeline that will check the context items Id against a setting where we will store the Id of the 404 page item in Sitecore and if the two match then update the response header.

The solution will look like this

Pipeline logic

1using Sitecore.Configuration;
2using Sitecore.Data;
3using Sitecore.Pipelines.HttpRequest;
4 
5namespace Pipelines.HttpRequest
6{
7    public class PageNotFoundResponseHeader : HttpRequestProcessor
8    {
9        private static readonly string PageNotFoundID = Settings.GetSetting("PageNotFound");
10 
11        public override void Process(HttpRequestArgs args)
12        {
13            if (Sitecore.Context.Item != null && Sitecore.Context.Item.ID == new ID(PageNotFoundID))
14            {
15                args.Context.Response.TrySkipIisCustomErrors = true;
16                args.Context.Response.StatusCode = 404;
17                args.Context.Response.StatusDescription = "Page not found";
18            }
19        }
20    }
21}

Patch config file

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
2  <sitecore>
3    <pipelines>
4      <httpRequestEnd>
5        <processor
6          patch:after="processor[@type='Sitecore.Pipelines.PreprocessRequest.CheckIgnoreFlag, Sitecore.Kernel']"
7          type="Pipelines.HttpRequest.PageNotFoundResponseHeader, MyProjectName"  />
8      </httpRequestEnd>
9    </pipelines>
10    <settings>
11      <!-- Page Not Found Item Id -->
12      <setting name="PageNotFound" value="ID of 404 Page" />
13    </settings>
14  </sitecore>
15</configuration>

What's the TrySkipIisCustomErrors property

Quite simply this stops a scenario where you end up on IIS's 404 page rather than your own. If you don't set this, when you update the header status code to 404, IIS likes to return the page from it's settings rather than continuing with your own.