Security

Of 22 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://js.smile.io/v1/smile-shopify.js?shop=sprinkle-pop.myshopify.com - https://www.googletagmanager.com/gtag/js?id=G-DJE56K4YGG&cx=c&gtm=4e6562 - https://connect.facebook.net/signals/config/638205776367600?v=2.9.313&r=stable&domain=sprinklepop.shop&hme=97937018cefade17726f0472876fc101316b2ce9008a35a6a5a7977d7436151a&ex_m=104%2C205%2C154%2C22%2C72%2C73%2C145%2C68%2C67%2C11%2C162%2C90%2C16%2C138%2C48%2C146%2C77%2C112%2C47%2C127%2C39%2C75%2C78%2C134%2C159%2C164%2C8%2C4%2C5%2C7%2C6%2C3%2C91%2C101%2C165%2C170%2C219%2C62%2C186%2C187%2C55%2C276%2C30%2C74%2C231%2C230%2C229%2C23%2C33%2C103%2C61%2C10%2C63%2C97%2C98%2C99%2C105%2C130%2C31%2C29%2C132%2C133%2C129%2C128%2C155%2C76%2C158%2C156%2C157%2C50%2C60%2C123%2C15%2C161%2C45%2C263%2C264%2C262%2C26%2C27%2C28%2C18%2C20%2C44%2C40%2C42%2C41%2C83%2C92%2C96%2C110%2C144%2C147%2C46%2C111%2C24%2C21%2C119%2C69%2C36%2C149%2C148%2C150%2C141%2C139%2C25%2C35%2C59%2C109%2C160%2C70%2C17%2C152%2C114%2C81%2C66%2C19%2C85%2C86%2C116%2C84%2C136%2C135%2C34%2C278%2C293%2C212%2C201%2C202%2C200%2C296%2C288%2C52%2C213%2C107%2C131%2C80%2C121%2C54%2C49%2C113%2C120%2C126%2C58%2C64%2C151%2C115%2C37%2C32%2C53%2C56%2C100%2C163%2C1%2C124%2C14%2C122%2C12%2C2%2C57%2C93%2C65%2C118%2C89%2C88%2C166%2C167%2C94%2C95%2C9%2C125%2C102%2C51%2C142%2C87%2C79%2C71%2C117%2C106%2C43%2C143%2C0%2C82%2C137%2C140%2C153%2C38%2C108%2C13%2C168 - https://connect.facebook.net/en_US/fbevents.js - https://c.amazon-adsystem.com/aat/amzn.js 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.

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

This only monitors, it doesn't block spoofed emails. Change to p=quarantine or p=reject after monitoring DMARC reports.

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

A short max-age leaves a window for downgrade attacks. Set max-age to at least 31536000 (1 year).

Without the Secure flag, this cookie can be sent over unencrypted HTTP, exposing it to interception.

security.txt (RFC 9116) provides a standardized way for security researchers to report vulnerabilities. Create one at /.well-known/security.txt with at least a Contact field.

Without rel="noopener", the destination tab can navigate the original tab via window.opener -- a reverse-tabnabbing phishing primitive. Modern browsers default to noopener since Chrome 88 / Firefox 79 / Safari 12.1, but explicit rel="noopener noreferrer" remains the documented best practice for older browsers, in-app webviews, and security scanners.

Each `style=""` attribute forces `style-src 'unsafe-inline'` in any Content-Security-Policy, which negates most of CSP's XSS-mitigation value. 31 inline style(s) is moderate. Affected element types include: div, a, img, iframe. 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.

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)`.

Without an explicit `Referrer-Policy` header, the browser falls back to its default policy. Modern browsers (Chrome 85+, Firefox 87+, Safari 15+) default to `strict-origin-when-cross-origin`, which is privacy-safe. Legacy browsers default to the leaky `no-referrer-when-downgrade`, which sends the full URL (including path + query) on cross-origin HTTPS-to-HTTPS requests. Set an explicit header to ensure consistent behavior: ``` Referrer-Policy: strict-origin-when-cross-origin ``` This matches the modern browser default and is privacy-safe without breaking referrer-based same-origin analytics.

Introspection lets clients query the GraphQL server for its complete schema -- every type, field, argument, and resolver name. Convenient during development; on production, an attacker uses it as a free recon tool to map the entire data graph. Disable in production unless your API is intentionally public-spec.

Detected via: cf-ray: 9f98f45c4d5e6f87-CDG

Consider adding a security.txt at /.well-known/security.txt.

The server advertises HTTP/3 via Alt-Svc for faster connections on mobile networks.