B-81%
Quality Score
7
Pages
105
Issues
8.1
Avg Confidence
8.0
Avg Priority
47 Critical42 High16 Medium
>_ Testers.AI
AI Analysis
Mylifebox was tested and 105 issues were detected across the site. The most critical finding was: Unconsented third-party analytics/tracking scripts loaded on homepage. Issues span Security, A11y, Performance, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (5/10).
Qualitative Quality
Mylifebox
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
mylifebox.com
mylifebox.com
mylifebox.com
mylifebox.com
mylifebox.com
mylifebox.com
Detected Issues · 105 total
1
Unconsented third-party analytics/tracking scripts loaded on homepage
CRIT P9
Prompt to Fix
Actionable prompt: In the homepage HTML, ensure that all analytics scripts (Optimizely bundle, Google Analytics gtag, and Google Tag Manager) load only after user consent. Implement a Consent Management Platform (CMP) or consent gate. Remove automatic firing of analytics calls on page load; wrap script injections behind a consent check. For example, initialize a consent flag window.hasConsent = false until user accepts; conditionally inject the script tags or load them via a function that runs after consent. Ensure GA measurement IDs are activated only after consent and that no PII is sent in initial requests. Audit analytics requests to remove or obfuscate any personally identifiable data. Update privacy policy and cookie banner text to reflect cross-site tracking and third-party sharing.
Why it's a bug
The site loads multiple third-party tracking and analytics scripts (Optimizely, Google Analytics/Tag Manager). In the absence of explicit user consent indicators in the provided activity, these calls enable cross-site tracking and data collection without visible user consent, potentially violating privacy expectations and regulations.
Why it might not be a bug
If a robust consent mechanism (cookie banner/CMP) is present and configured to block analytics until consent is given, this would mitigate risk. However, the provided activity does not show any consent gating evidence.
Suggested Fix
Implement a consent management workflow. Delay loading of Optimizely and Google Analytics/Tag Manager scripts until the user has given explicit consent. Use a CMP to capture consent for analytics and personalization. Ensure that analytics requests do not send PII or user identifiers before consent. Consider using privacy-friendly analytics options or server-side tagging with data minimization.
Why Fix
Protects user privacy, reduces data leakage risk, and aligns with privacy regulations and user expectations. Improves trust and reduces potential legal/regulatory exposure.
Route To
Frontend Developer / Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
⚠️ POTENTIAL ISSUE: Tracking request detectedNetwork:
https://cdn.optimizely.com/js/25722630004.js; https://www.googletagmanager.com/gtag/js?id=DC-14579985; https://mylifebox.com/scripts/gtag/global-snippet.js; https://www.googletagmanager.com/gtag/js?id=G-4P95MTS1F8; https://www.googletagmanager.com/gtm.js?id=GTM-K7M93RG2
PII-like unique user identifier transmitted in analytics requests (auid parameter in ccm.collect)
CRIT P9
Prompt to Fix
In the Google CCM collect call, remove the auid parameter or replace with a non-identifying transient token derived from a per-session salt stored in a cookie. Do not expose user-identifying data in URL query strings. Ensure consent for analytics and switch to privacy-preserving analytics where feasible.
Why it's a bug
The analytics request to https://www.google.com/ccm/collect includes a parameter 'auid' with a value '1557252329.1774519978', which appears to be a unique user identifier. Transmitting this identifier in the URL/query string can be logged by servers, analytics providers, and intermediate proxies, enabling user-level profiling or correlation with other data. This is a privacy risk and may violate data minimization principles and privacy regulations if it can be linked to an individual.
Why it might not be a bug
If auid is strictly an internal, temporary, non-identifying session token that cannot be linked to a real person, it may be considered non-PII. However, since it's included in a URL and could be logged, it should not be trusted without confirmation. Given the lack of clarity, this should be treated as a potential PII exposure.
Suggested Fix
Remove the 'auid' parameter from the query string or replace it with a non-identifying, ephemeral token stored in cookies and used server-side for mapping if needed. Ensure analytics payload carries no user-identifying information in URL parameters. Introduce a consent gate before collecting analytics data.
Why Fix
Eliminates potential exposure of unique user identifiers in logs and external analytics systems, improving privacy compliance and user trust.
Route To
Frontend Engineers, Backend/Analytics Engineers
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Network:
POST https://www.google.com/ccm/collect?frm=0&ae=g&en=page_view&dl=https%3A%2F%2Fmylifebox.com%2Fen%2Ffaq.html&auid=1557252329.1774519978&navt=n&npa=0&ep.ads_data_redaction=0>m=...&gcd=13l3l3l3l1l13
Exposed Firebase API key in frontend config (firebaseConfig.js)
CRIT P9
Prompt to Fix
Action: Remove exposing apiKey from frontend. Implement a secure config fetch: create a backend endpoint /config/firebase that requires authentication and returns only non-secret identifiers (e.g., projectId) or use environment-based configuration loaded at build time. Enable Firebase App Check in the Firebase console. Limit API key usage to allowed HTTP referrers and/or IP addresses. Review Firestore/Realtime Database security rules to ensure proper authentication is required for reads/writes. If a backend is not used, replace firebaseConfig.js with a minimal config or move to server-side rendering context that hides sensitive values.
Why it's a bug
Frontend loads firebaseConfig.js which contains Firebase config including apiKey. Although Firebase API keys are not strictly secret, exposing them publicly can allow misuse if security rules are weak or App Check isn't enabled. This increases risk of quota abuse, data access if misconfigured, and attack surface.
Why it might not be a bug
Firebase API key alone is not a secret and Firebase security rules/App Check typically protect data. However, relying on this assumption is risky; best practice is to minimize exposure and enforce proper security rules.
Suggested Fix
Move configuration to a backend-provisioned mechanism or load it only in secure contexts; enable Firebase App Check; restrict API key usage by HTTP referrers or IPs in Firebase console; enforce strict Firestore/Realtime Database rules; consider API gateway/proxy to control access.
Why Fix
Reducing exposure of sensitive config and enforcing proper access controls mitigates risk of unauthorized use or quota exhaustion if the key is discovered.
Route To
Security Engineer
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Console:
firebaseConfig.js loaded from frontend; contains API keyNetwork:
GET https://mylifebox.com/firebaseConfig.js