Security

Each `style=""` attribute forces `style-src 'unsafe-inline'` in any Content-Security-Policy, which negates most of CSP's XSS-mitigation value. 175 inline style(s) is high. Affected element types include: div, ul, svg, span, section. Move styles to a stylesheet; use CSS custom properties for runtime-dynamic values; or adopt a nonce/hash CSP policy. Most teams take the stylesheet path because it's also a maintainability win.

Of 77 third-party `<script>` / `<link rel=stylesheet>` resources, 0 (0%) declare a Subresource Integrity hash via the `integrity=` attribute. SRI binds the page to the exact bytes of the third-party resource: if the CDN is compromised, attacker-modified bytes won't match the declared hash and the browser refuses to execute the resource. Missing SRI on (first 5 examples): - https://b.stripecdn.com/mkt-ssr-statics/assets/_next/static/css/f4882a34561e5dbb.css - https://b.stripecdn.com/mkt-ssr-statics/assets/_next/static/css/9783a0f920ab0abb.css - https://b.stripecdn.com/mkt-ssr-statics/assets/_next/static/css/57f8c646aef0b9c7.css - https://b.stripecdn.com/mkt-ssr-statics/assets/_next/static/css/a11fd5697c32b98a.css - https://b.stripecdn.com/mkt-ssr-statics/assets/_next/static/css/1b1130e6e7ae0de3.css Fix: add `integrity="sha384-..."` and `crossorigin="anonymous"` attributes. Generators: srihash.org, or in-browser via `await crypto.subtle.digest('SHA-384', bytes)`. Cache-bust the resource URL when you change versions, since the integrity hash will mismatch with old cached bytes.

The legacy browser default (Chrome <85, Firefox <87). Sends the full URL (path + query) Referer on cross-origin requests as long as the protocol doesn't downgrade. This means session IDs, tracking tokens, search queries, etc. embedded in URLs leak to every third-party HTTPS origin the page links to or embeds. Switch to `strict-origin-when-cross-origin`.

Without SRI, if this CDN is compromised, attackers could inject malicious code.

Consider adding a Permissions-Policy header to restrict browser feature access from embedded content.

Response headers don't match any known WAF or bot-management product. Sites exposed to abuse (login, signup, payment) typically benefit from a WAF such as Cloudflare, Akamai, AWS WAF, or Imperva.

Trusted Types (CSP3) is a Chrome 83+ defense that requires DOM-XSS sinks (innerHTML, document.write, eval, ...) to receive a typed-and-sanitized value rather than a raw string. Adding `Content-Security-Policy: require-trusted-types-for 'script'; trusted-types default` neutralizes most DOM-XSS even when a payload reaches a sink. Adoption is currently ~0.1% of pages so this is informational; a roll-out usually starts in report-only mode.

Without a `Permissions-Policy` (or legacy `Feature-Policy`) header, every powerful browser feature defaults to its spec default policy (typically `self`). A third-party iframe injected via XSS or a misconfigured embed can still request access to the user's camera, microphone, geolocation, payment APIs, USB devices, etc. Explicitly deny features the page doesn't need: ``` Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=() ``` Features the page legitimately uses can stay enabled with `feature=(self)`.

HTTP/3 eliminates head-of-line blocking. If your CDN supports it, consider enabling it.