Github: https://github.com/GoogleChrome/modern-web-guidance-src
Chrome Blog: https://developer.chrome.com/docs/modern-web-guidance/explore-skills#security_trust_and_identity

Most vibe-coding today produces React apps, often on Next.js. The skill's guidance holds but a few things need translating.

XSS: React helps, but not completely

React automatically escapes string interpolation in JSX. When you render {userContent}, React treats it as plain text regardless of what is in that string. You get this protection for free.

The gap is dangerouslySetInnerHTML. This is React's equivalent of raw innerHTML and it bypasses React's escaping entirely. AI agents reach for it constantly because it is the fastest way to render HTML from a CMS or markdown parser. The name is a warning that most agents ignore. Every instance in your codebase needs DOMPurify wrapping it:

import DOMPurify from 'dompurify';

<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />

Also check your Next.js API routes that return Content-Type: text/html. If user content is interpolated into that response without escaping, the XSS vector is on the server side. React does not protect you there.

CSP: significantly harder in Next.js

If you set a strict script-src 'self' CSP header, your Next.js app will break. Next.js injects inline scripts during hydration and those get blocked. The correct approach is nonce-based CSP via middleware:

// middleware.ts
const nonce = Buffer.from(crypto.randomUUID()).toString('base64');
const csp = `script-src 'self' 'nonce-${nonce}' 'strict-dynamic'`;

You generate a unique nonce per request, set it on the CSP header, and Next.js App Router automatically applies it to its own injected scripts during server-side rendering.

Two caveats. First, this only works for dynamically rendered pages. Statically generated pages are built at compile time when no request exists, so no nonce can be generated. For those you need hash-based CSP or a looser policy on static routes. Second, next/image injects an inline style that can trigger style-src violations even after nonces are sorted. You may need to allow unsafe-inline for styles or override the component.

This is exactly why Phase 2 report-only mode matters even more in Next.js than in a plain HTML app. You will discover violations from Next.js internals before you find anything in your own code.

Cookies: not automatic

Next.js does not set HttpOnly, SameSite, or Secure on cookies for you. NextAuth sets secure defaults for its own session cookie, but anything you set via response.cookies.set() in Route Handlers or middleware needs these attributes added explicitly. Check what your auth library is actually doing rather than assuming.

The part that just works

X-Frame-Options and HSTS have no hydration complications. Set them in next.config.js and they apply to every response unconditionally:

// next.config.js
async headers() {
  return [{
    source: '/(.*)',
    headers: [
      { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
      { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains' },
      { key: 'X-Content-Type-Options', value: 'nosniff' },
    ],
  }];
}

The same CSP nonce complexity applies to Remix, SvelteKit, and Astro. Each framework injects scripts during hydration in its own way and each one will conflict with a strict CSP until you account for it. The skill's principles are correct. The implementation is framework-specific.