Why I realized publishing a lib like this might be a bad idea ... [and how it could get better]

[nibtime]

... because there are parts that require integration with framework internals that can change any upcoming canary build without notice and be released with any patch version and break things for this lib.

I realized this with the latest Next 12.2 updates. There has been a huge load of internal changes that broke the lib, and as they are internal they don't obey SemVer and ensure backward compatibility in any way. It will be impossible for me to maintain something like this.

I will keep observing this for a bit. If those changes were exceptional due to the transition to stable middleware, experimental-edge runtime, RSC/Streaming, etc. I will keep the lib public and continue to maintain it.

If they are the rule, I will convert this to a private project and package and maintain it for myself and my colleagues, so I don't have to obey the rules of a publicly available lib. It is a security lib after all, and if establishing stability should be incompatible with the Next.js release cycle, I think it is unfair to offer it at all.

That's why I think it would be better if Next.js offered this at the framework level, where it is maintained and tested along the other framework internals, like other popular site generators already do:

https://kit.svelte.dev/docs/configuration#csp
https://nuxtjs.org/docs/configuration-glossary/configuration-render/#csp

Alternatives

https://github.com/google/strict-csp
https://github.com/guydumais/next-strict-csp

[nibtime]

I gave it some thought and I think the main problem regarding maintainability is that it is the single package that depends on latest Next as a whole.

I am working on a PR to refactor the lib atm and split it up into many small modules. That paves the way for splitting up the lib in smaller packages that can have different peer dep requirements. While doing, I also saw potential to support more setups/versions of Next and a good way to support next export, which also decouples the thing from Vercel and opens up the way for more hosting providers.

This way I can put out major releases gradually for the stuff that works and is tested and keep the more experimental packages in the minors. When I put out a major release for something, I won't change public APIs/functions anymore and obey to SemVer, while with 0. version I might introduce breaking changes with any next minor release (but try to avoid if I can of course).

Edit: I converted the package design to an issue: #66

[renet]

Just a very basic question about the middleware and how I understand how it can be used:

According to the Next.js documentation, the middleware gives you a NextResponse object that is in fact extending the Response interface of the native fetch API. Wouldn't this mean that one can simply analyze the response.body (e.g. await response.text()) and hand it over to for example Google's strict-csp and get all the CSP directives you need including all the hashes? What exactly are the advantages of using a Next.js specific approach then? Is it performance, or is it Next.js internals that cannot be covered by just analyzing the HTML output?

I know this might be a stupid question and I have to admit that I'm new to CSP, haven't been testing strict-csp yet and don't really know much about Next.js internals or middleware-specific specialties. However it would be nice, if you helped me understand (please don't feel obliged to go into any detail, a short hint in the right direction would be enough). Thanks! :)

[nibtime]

On the middleware part

• You can only get a handle on the future response with NextResponse.next(), and add/set additional headers and cookies to be included in the future response. But you can't access or set the response body or get the headers/cookies of the future response in middleware. So there is no way to get the HTML that is going to be returned.

• Actually there is: you could fetch the static page in middleware and process it with cheerio (surprisingly it is V8 compatible, you can use it in middleware), I did tried that in the very beginning of prototyping. However, that has 2 major problems:

  1. if you fetch the whole page on every request in middleware and parse/process it with cheerio, middleware would likely take to long to execute on average and slow down you site perceivably.
  2. Furthermore If you host on Vercel, there's a limit of 50ms per request on average for CPU utilization for middleware. You would very likely get an E-Mail from Vercel soon that tells you to either reduce that, remove your middleware or get your account closed. (also see excessive CPU usage warning from Vercel for middleware #45). I had to do some optimizations to reduce it for this lib (went down from 30-40ms to 5-20ms) and things I got rid of were far less than parsing and processing full HTML documents, it was stuff like unnecessary double-setting headers, calling toString() and uniq calls on arrays, etc.

The advantages of the Next integration over google/strict-csp

• Can support HTTP Response header and thus reporting/report-only mode
• Can support strict inline styles, for CSS-in-JS framework like emotion, Stitches, etc.
• Can support hybrid apps with ISR that require a mix of Nonce-based and Hash-based (Next.js internal)
• Will block scripts even from HTML injections of dynamic data fetched via getStaticProps/getServerSideProps (Next.js internal)
• strict-csp replaces scripts with an inline loader, which would totally mess up the script loading of Next.js (Next.js internal)

That being said, I want to support other configuration options than middleware. All the above stuff would become the @strict-csp/next-ssr package. The @strict-csp/next-headers will take some ideas from strict-csp and be an additional configuration option to decouple configuration from middleware and the latest Next release cycles, but with the above-mentioned advantages.

What I learned from this package is, that I wouldn't have created it, if I knew how much work it would be :). I went into it and thought just hash/process some HTML with cheerio, np but getting it to work reliably took me ages, because there are strange edge cases all over the place.

In general, expecting HTML files to be present for processing limits the usage of Next.js fundamentally, as it means that you had to refrain from all revalidation features (ISR). You had to decide between the two, as all responses to revalidate requests won't include the processing and be completely broken by CSP blocking. A good reference for HTML processing with cheerio can be found here: vercel/next.js#23993 (comment).

The lib is doing something similar for inline styles already, also with cheerio, but in a way that does not rely on HTML files, it processes initialProps.html on the fly. This way it can even make things work for inline styles with getServerSideProps, e.g. by adding style attribute hashes in HTML to CSP per request etc. Stuff like this can only be achieved with CSP processing in terms of the framework, i.e. generic processing doesn't know that getStaticProps, getServerSideProps, and ISR are a thing.

Update: I tried out the strict-csp webpack plugin with the e2e app, naively adding the plugin as described in docs. As output I get a file .next/server/index.html, that does nothing. But I don't know too much about webpack and how the WebpackHtmlPlugin plays together with Next.js TBH:

Output of google/strict-csp with the e2e app

<!DOCTYPE html>
<html>
  <head>
    <meta
      http-equiv="Content-Security-Policy"
      content="script-src 'strict-dynamic' 'sha256-bDS42aVXSmZ3nfsEEK39yVG6qKbrptYpCZpPiyH9Rc0=';object-src 'none';base-uri 'self';"
    />
    <meta charset="utf-8" />
    <title>Webpack App</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
  </head>
  <body>
    <script>
      var scripts = ["/_next/edge-runtime-webpack.js", "/_next/middleware.js"];
      scripts.forEach(function (scriptUrl) {
        var s = document.createElement("script");
        s.src = scriptUrl;
        s.async = false; // preserve execution order.
        document.body.appendChild(s);
      });
    </script>
  </body>
</html>

[nibtime]

I discovered this: https://github.com/nessjs/ness, as it also has a CSP integration for Next.

That looks like a great option to host Next.js independent from Vercel at a good budget. I will test to see if it works with middleware and if I can integrate it with the Strict CSP features of this lib.

[MartinN3]

Im really glad i found this lib as it helped me a lot with CSP in Nextjs (problem is ongoing tho). I would suggest that we point to this announcement in the beginning of readme.