B-82%
Quality Score
7
Pages
133
Issues
8.0
Avg Confidence
7.9
Avg Priority
57 Critical53 High22 Medium1 Low
>_ Testers.AI
AI Analysis
Emergent was tested and 133 issues were detected across the site. The most critical finding was: Unconsented third-party analytics scripts loaded (GA/Tag Manager). Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).
Qualitative Quality
Emergent
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
emergent.sh
emergent.sh
emergent.sh
emergent.sh
emergent.sh
emergent.sh
Detected Issues · 133 total
1
Unconsented third-party analytics scripts loaded (GA/Tag Manager)
CRIT P9
Prompt to Fix
Add a consent banner (CMP) and guard all third-party analytics by checking a consent flag before loading external scripts. Specifically, replace direct script tags for GTM/GA with a loader that only injects <script src=...> elements after user consent is granted. Ensure no data (including IP or identifiers) is transmitted to Google Analytics before consent. Document the consent workflow in code comments and privacy policy.
Why it's a bug
The page loads multiple third-party tracking scripts (Google Tag Manager, GA4, Google Ads) which enable cross-site user tracking. There is no evidence of an explicit consent mechanism or CMP gating these requests in the logs, increasing risk of privacy regulation violations and user profiling without consent.
Why it might not be a bug
Some sites preload analytics by default; however, prevailing privacy best practices require explicit user consent before tracking. Absence of consent gating in network activity is a clear privacy risk and should be treated as a high-priority issue.
Suggested Fix
Implement a consent management platform and gate all third-party analytics scripts (gtm.js, gtag.js) behind explicit user consent. Load GA/Tag Manager only after consent; ensure requests do not send data before consent is given; consider data minimization and anonymization where possible.
Why Fix
Reduces privacy risk, improves regulatory compliance (GDPR/CCPA), and increases user trust by ensuring tracking occurs only with consent.
Route To
Privacy Engineer / Frontend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
Consent UI not evident; no clear consent gating observed for analytics scripts in network logs.Network:
GET https://www.googletagmanager.com/gtm.js?id=GTM-NCCB99P9 - Status: N/A2
PII in analytics pixel 'em' parameter exposed to Meta Pixel
CRIT P9
Prompt to Fix
Prompt: Remove all raw PII (emails) from analytics calls to third-party services. Ensure the code does not set the 'em' parameter for Meta Pixel. If email analytics are required, implement consent checks, then hash the email with SHA-256 and send only the hash (or use a non-PII user identifier). Add strict input validation to prevent emails from being formed or sent to analytics. Review all analytics integration points for PII exposure and remove or redact sensitive fields.
Why it's a bug
Console shows an attempt to send an email address to Meta Pixel via the 'em' parameter. This constitutes PII being transmitted to a third-party service. While the log notes the email is invalid and will not be sent, the presence of the parameter indicates potential data exposure and privacy/regulatory risk if the value were valid or if other sensitive data is passed.
Why it might not be a bug
The log explicitly states the email is invalid and that data will not be sent, implying the system prevents leakage in this instance. If input validation and consent-driven data sharing are correctly enforced, this specific instance may not result in actual data exfiltration.
Suggested Fix
Remove the 'em' parameter from all analytics calls to third-party services. Do not pass raw emails to analytics. If user-level analytics are required, implement consent checks and use privacy-preserving techniques (e.g., hashing the email with SHA-256 after obtaining user consent, or use non-PII identifiers). Validate inputs strictly before sending any data to external services and audit all analytics calls for PII exposure.
Why Fix
Preventing transmission of PII to third-party analytics reduces regulatory risk, protects user privacy, and prevents potential credential/identity exposure via misconfigured analytics integrations.
Route To
Privacy Engineer / Security Engineer
Page
Tester
Sharon · Security Console Log Analyzer
Technical Evidence
Console:
[WARN] [Meta Pixel] - An invalid email address was specified for 'em'. This data will not be sent with any events for this Pixel.3
Third-Party Script Attack Surface due to multiple external JS resources without integrity checks
CRIT P9
Prompt to Fix
Actionable fix: 1) Add a CSP header in production responses: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com https://framerusercontent.com https://static.claydar.com; object-src 'none'; connect-src 'self'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; report-uri /csp-violation-report 2) Implement Subresource Integrity (SRI) for every external script tag. For each external script, compute the SHA-256/384/512 hash of the exact file contents and add an integrity attribute, e.g.: <script src="https://www.googletagmanager.com/gtm.js?id=GTM-NCCB99P9" integrity="sha256-ABC..." crossorigin="anonymous"></script>. Do the same for all scripts listed in the trace (gtm.js, gtag.js, framerexternal JS, claydar init, etc.). 3) If feasible, move critical scripts to a first-party domain or a tightly controlled CDN and restrict CSP to that domain. 4) If inline scripts are necessary, switch to nonce-based CSP and ensure the server supplies a fresh nonce per response. 5) Add a CSP violation-_report endpoint to monitor and log violations in production and adjust the allowlist accordingly. 6) Update CI/CD to verify presence of CSP and SRI attributes for all external scripts before deployment.
Why it's a bug
The page loads numerous external JavaScript assets from multiple third-party domains (e.g., googletagmanager.com, framerusercontent.com, static.claydar.com, events.framer.com, etc.). This expands the attack surface: if any third-party asset is compromised, it could inject malicious code, exfiltrate data, or alter page behavior. The network trace shows no evidence of Subresource Integrity (SRI) or a restrictive Content Security Policy (CSP) to constrain these resources, increasing risk of XSS, data leakage, or drive-by compromises.
Why it might not be a bug
External analytics and UI libraries are common; however, without proper mitigations (SRI and CSP), the risk remains elevated. This is a configuration/security posture issue rather than a bug in business logic and should be prioritized due to potential impact on users.
Suggested Fix
1) Implement a strict Content Security Policy (CSP) header that whitelists only trusted script origins (e.g., 'self' and approved domains such as https://www.googletagmanager.com, https://framerusercontent.com, https://static.claydar.com, etc.). 2) Add Subresource Integrity (SRI) integrity attributes to all external script tags and ensure crossorigin="anonymous" is set. 3) Consider hosting critical scripts on a first-party domain or a tightly controlled CDN and remove unnecessary third-party scripts. 4) Use a nonce-based CSP if inline scripts are required. 5) Add a CSP violation report endpoint to monitor violations in production.
Why Fix
Mitigates risk of XSS, code injection, and data exfiltration from compromised third-party scripts. Improves overall security posture when loading many external resources.
Route To
Security Engineer
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Network:
https://www.googletagmanager.com/gtm.js?id=GTM-NCCB99P9 https://framerusercontent.com/sites/5wwxZ4vetC9TakzxYj8prf/react.BVXKyxYy.mjs https://www.googletagmanager.com/gtag/js?id=G-SDS4HXTY21