Basic security-oriented HTTP headers are defined in the next.config.js file, such as X-DNS-Prefetch-Control, X-XSS-Protection and X-Content-Type-Options. The Strict-Transport-Security header is automatically added by Vercel.

A rather strict Content-Security-Policy HTTP header is defined in the next.config.js file. It should forbid most things that are not expected.

Unfortunately, it does not forbid inlined <script> elements since Next.js relies on such a script for client-side rehydration. A potential solution would be to set up a nonce, but Next.js is not quite ready for that yet.

All API routes (in /pages/api) are protected with rate limiting as well as some artificial slowness when they get pinged too frequently by the same IP address.

Note that Vercel does have some form of rate limiting on its side to avoid ever going down. That being said, it’s very high and doesn’t help much against low volume scripted attacks.

API keys and environment secrets are defined on Vercel and GitHub and never passed to the client. This is ensured via Next.js handling of environment variables — only variables prefixed with NEXT_PUBLIC_ make their way into the bundle.

Semi-authenticated API routes, such as the one for the CMS preview or the one for the cache invalidation rely on a secret environment variable that is exposed via Vercel, and thus only available in API routes.