B+87%
Quality Score
5
Pages
97
Issues
7.6
Avg Confidence
7.7
Avg Priority
28 Critical54 High15 Medium
>_ Testers.AI
AI Analysis
GAME scored B+ (87%) with 97 issues across 7 tested pages, ranking #2 of 20 UK retail sites. That's 33 fewer than the 130.2 category average (90th percentile).
Top issues to fix immediately: "Missing product images causing broken visual layout in game grid" — Ensure all product image URLs are properly configured and pointing to valid, accessible resources; "Multiple images with empty or missing alt text" — Add descriptive alt text to all informative images; "Multiple failed resource loads prevent essential page functionality" — Investigate and resolve DNS resolution issues causing net::ERR_NAME_NOT_RESOLVED errors.
Weakest area — accessibility (5/10): Contrast ratios may be problematic with purple/magenta backgrounds. Missing clear alt text indicators, heading hierarchy unclear.
Quick wins: Improve color contrast ratios to meet WCAG AA standards, particularly for text on colored backgrounds. Add clear alt text to all product images and implement proper heading hierarchy (H1, H2, H3).
Qualitative Quality
GAME
Category Avg
Best in Category
Pages Tested · 5 screenshots
Homepage
game.co.uk
game.co.uk
game.co.uk
game.co.uk
Detected Issues · 97 total
1
AI/LLM Endpoints Invoked on Page Load Without User Consent
CRIT P9
Prompt to Fix
Review all network requests marked as AI/LLM endpoints. For each endpoint with 'genai' in the name or encoded paths that call AI services, implement: (1) User consent check before the request - do not make the call if user hasn't explicitly opted in, (2) Clear privacy notice in the footer/settings explaining which AI services are used, (3) Move all non-essential AI calls behind user interaction events, not page load. Create a Privacy.md document listing all third-party AI services and their purposes. For the POST request to the encoded endpoint, add logging to understand what data it sends and receive a clear business justification for why it must run on page load.
Why it's a bug
Multiple network requests marked with ⚠️ AI/LLM ENDPOINT DETECTED show AI service calls being made immediately on page load. These include requests to ambiguous endpoints like 'game-genai-easter' image URLs and POST requests to encoded paths that appear to be AI service endpoints. This violates user privacy expectations - users should explicitly consent before any AI processing of their data occurs. The calls fire before user interaction, which is a red flag for GenAI code that wasn't properly constrained.
Why it might not be a bug
Some AI endpoints may be legitimate first-party services for page rendering. However, the lack of transparency about what these endpoints do and when they're called is problematic.
Suggested Fix
Implement explicit user consent mechanisms before invoking any AI/LLM endpoints. Defer all non-critical AI calls to user interaction (clicks, form submission). Add clear privacy disclosures about what AI services are used and why. Audit all 'game-genai' and encoded endpoint references to understand their purpose. Remove or conditionally load any AI endpoints that fire without explicit user action.
Why Fix
Invoking AI services without consent violates GDPR, CCPA, and basic privacy principles. Users have the right to know when their data is being processed and by whom. This could result in legal liability and loss of user trust.
Route To
Privacy Engineer, Security Engineer, Frontend Lead
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTED appears 11 times in network activityNetwork:
GET https://cdn.media.amplience.net/i/frasersdev/game-genai-easter-94098599-75743669-89420006-77752790-2x1 - ⚠️ AI/LLM ENDPOINT DETECTED, GET https://www.game.co.uk/3F7pgiAs/igzS4v6/rSP5Pk_/No/V37DSNiQOO1NrQ/DFxcZFd6PAI/EWZ3GFk/pfV8B - ⚠️ AI/LLM ENDPOINT DETECTED2
Sensitive OAuth State Parameter Exposed in Google Analytics Tracking URLs
CRIT P9
Prompt to Fix
Audit all OAuth and authentication flow code where the state parameter is generated and used. Remove any user-identifiable information, return URLs, or sensitive metadata from the state parameter value. Ensure that state parameters are not included in any analytics, tracking, or logging requests sent to third-party services like Google Analytics. Use opaque, server-side-managed tokens for OAuth state instead of encoding sensitive information. Update the analytics tag manager configuration to exclude OAuth-related URL parameters from tracking URLs sent to Google.
Why it's a bug
The OAuth state parameter containing sensitive redirect information is being transmitted to Google Analytics and Google Tag Manager in multiple tracking requests. The state parameter is Base64-encoded JSON containing the original return URL (https://www.game.co.uk/accountinformation), which reveals the user's intended destination and internal application flow. This sensitive authentication metadata should never be transmitted to third-party analytics services as it could enable attack vectors and privacy violations.
Why it might not be a bug
State parameters are typically considered non-sensitive as they are meant to be opaque tokens. However, in this case the state contains readable return URL information that exposes internal application structure and user navigation intent to third parties.
Suggested Fix
Remove the full URL from the state parameter or use an opaque, encrypted token instead. Do not include the state parameter or any OAuth metadata in analytics tracking requests. Implement server-side session tracking for analytics that doesn't expose authentication flow details.
Why Fix
Exposing OAuth state parameters and return URLs to third-party analytics services violates privacy principles, enables cross-site tracking with authentication context, and exposes internal application structure to Google. This could facilitate targeted attacks or privacy-invasive profiling.
Route To
Security Engineer / Authentication Team Lead
Page
Tester
Pete · Privacy Networking AnalyzerTechnical Evidence
Console:
OAuth state parameter transmission in analytics requestsNetwork:
POST https://www.google-analytics.com/g/collect with dl parameter containing state=eyJhIjoiMCIsIm4iOiJWRVF2dktQVCIsInIiOiJodHRwczovL3d3dy5nYW1lLmNvLnVrL2FjY291bnRpbmZvcm1hdGlvbiJ93
Session and Experience IDs Transmitted to Third-Party Analytics Services
CRIT P9
Prompt to Fix
Review all analytics tag implementations (Google Analytics and Google Tag Manager) to remove transmission of internal application session IDs and experience IDs. Search for session_id, experience_id, and any unique application identifiers in the analytics payload configuration. Either remove these parameters entirely from analytics requests, or replace them with generic, non-linkable session tokens that cannot be used to track users across your application or across time. Ensure that Google Analytics receives only aggregated, anonymized data that cannot be used to reconstruct individual user journeys.
Why it's a bug
Unique session_id (99322467-8ff9-47f5-864a-4be6ff4a9042) and experience_id (2d97aa72-c76c-4c81-ab1f-6ebe04340787) are being transmitted to Google Analytics and Google Tag Manager. These identifiers enable persistent cross-site tracking of individual users across their entire session. Combined with Google's own tracking identifiers (cid and ecid parameters), this creates a comprehensive user profile shared with third parties without explicit per-request consent indicators.
Why it might not be a bug
Session IDs are necessary for application functionality. However, transmitting them to third-party analytics services enables tracking that may exceed user expectations and consent.
Suggested Fix
Do not transmit application session_id or experience_id to third-party analytics services. If analytics requires session tracking, use anonymized, non-linkable identifiers generated specifically for analytics. Implement server-side analytics that don't require exposing application session identifiers to external services.
Why Fix
Sharing internal session identifiers with Google enables comprehensive user tracking across time and potentially across sites. This violates privacy principles and may violate GDPR/privacy regulations without explicit informed consent. Users do not typically expect their session IDs to be shared with analytics platforms.
Route To
Privacy Engineer / Data Protection Officer
Page
Tester
Pete · Privacy Networking AnalyzerTechnical Evidence
Console:
Session tracking parameter exposure in analyticsNetwork:
Multiple instances including POST https://www.google-analytics.com/g/collect containing session_id=99322467-8ff9-47f5-864a-4be6ff4a9042&experience_id=2d97aa72-c76c-4c81-ab1f-6ebe04340787