B+88%
Quality Score
5
Pages
88
Issues
7.5
Avg Confidence
7.5
Avg Priority
21 Critical45 High22 Medium
>_ Testers.AI
AI Analysis
Evans Cycles scored B+ (88%) with 88 issues across 6 tested pages, ranking #1 of 20 UK retail sites. That's 42 fewer than the 130.2 category average (95th percentile).
Top issues to fix immediately: "Missing Product Images Breaking Key Shopping Feature" — Verify that product image URLs are correctly configured in the product data feed and that the image CDN or server is ...; "Repeated DNS Resolution Failures - Critical Network Issue" — 1) Identify all resources returning ERR_NAME_NOT_RESOLVED by enabling detailed network logging with URLs; "Multiple Failed Resource Loads - Unresolved DNS or Missing Assets" — Audit all resource loading code to verify that endpoints are valid and resolvable.
Weakest area — accessibility (5/10): Limited alt text visible on images, small font sizes in some areas, and insufficient color contrast in certain sections.
Quick wins: Implement WCAG 2.1 AA compliant color contrast ratios and add descriptive alt text to all product images. Enhance mobile responsiveness visibility and create clearer product filtering/sorting options in main navigation.
Qualitative Quality
Evans Cycles
Category Avg
Best in Category
Pages Tested · 5 screenshots
Homepage
evanscycles.com
evanscycles.com
evanscycles.com
evanscycles.com
Detected Issues · 88 total
1
Sensitive Authentication State Exposed in URL Parameters During OAuth Flow
CRIT P9
Prompt to Fix
Fix the OAuth state parameter generation in the authentication flow. The current implementation embeds base64-encoded return URLs in the state parameter, which exposes application structure and violates OAuth security best practices. Change the implementation to: (1) Generate a cryptographically secure 32-character random hex token for the state parameter, (2) Store the mapping of this state token to the original return URL in server-side session storage (Redis or database) with a 10-minute TTL, (3) Pass only the random token to the OAuth authorize endpoint, (4) On callback, validate the state token exists in session storage and is not expired, then retrieve the return URL from the session. This prevents URL disclosure in logs/history and eliminates state parameter tampering risks.
Why it's a bug
The OAuth authorization flow exposes sensitive state data in URL parameters visible in network logs and potentially in browser history. The 'state' parameter contains base64-encoded JSON with the return URL and other session information. While state parameters are standard in OAuth, the encoding should use cryptographically secure random values without embedded return URLs. The base64 string 'eyJhIjoiMCIsIm4iOiItSU1kZ3ZkYyIsInIiOiJodHRwczovL3d3dy5ldmFuc2N5Y2xlcy5jb20vYWNjb3VudGluZm9ybWF0aW9uL29yZGVyaGlzdG9yeXN1bW1hcnkifQ==' decodes to sensitive redirect information. This is a GenAI anti-pattern where AI-generated OAuth implementations often incorrectly embed application data in OAuth state parameters rather than storing state server-side.
Why it might not be a bug
OAuth 2.0 allows custom state content for CSRF protection; however, embedding user-facing URLs in the state parameter is still poor security practice as it exposes application structure and creates audit trail issues.
Suggested Fix
Refactor the OAuth state parameter generation to use a cryptographically secure random token (e.g., 32-character hex string). Store the mapping between this random state and the return URL in server-side session storage (Redis, database) with a short TTL. Generate the state as: state = secure_random_token(); session.store(state, {returnUrl: url, timestamp: now()}); Only pass the random token in the OAuth request.
Why Fix
Reduces exposure of application URLs in browser history and logs, prevents state parameter tampering by users, and follows OAuth 2.0 security best practices. This prevents information disclosure vulnerabilities where attackers could enumerate application URLs from leaked OAuth requests.
Route To
Backend/Security Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
N/A - visible in network requestsNetwork:
GET https://auth.evanscycles.com/connect/authorize?client_id=...&state=eyJhIjoiMCIsIm4iOiItSU1kZ3ZkYyIsInIiOiJodHRwczovL3d3dy5ldmFuc2N5Y2xlcy5jb20vYWNjb3VudGluZm9ybWF0aW9uL29yZGVyaGlzdG9yeXN1bW1hcnkifQ%3D%3D2
Personal Data Exposed in Google Analytics and Ad Pixel Network Requests
CRIT P9
Prompt to Fix
Fix data privacy leakage to Google Analytics and ad tracking services. The current implementation sends full authenticated URLs containing OAuth state parameters, session IDs, and experience IDs to Google's analytics and ad measurement endpoints. This exposes sensitive session data to third parties. Implement the following: (1) Create a URL sanitization utility that strips query parameters from all tracked URLs before sending to analytics providers, (2) Replace all instances of pageUrl or URL variables sent to Google Analytics with sanitized versions (base URL only, no query strings), (3) Configure Google Analytics with anonymize_ip=true, (4) Switch to server-side event tracking for login/authentication events instead of sending URLs from the browser, (5) Document all data flows to third parties in privacy policy. This prevents unintended exposure of authentication state and personal session data to external services.
Why it's a bug
The network requests to Google Analytics and Google Ads measurement endpoints contain sensitive personal data including full authenticated URLs with OAuth state parameters, session IDs, experience IDs, and user email context embedded in the URL query strings and POST bodies. The POST request to 'pagead2.googlesyndication.com/measurement/conversion' and 'www.google-analytics.com/g/collect' include the full OAuth callback URL with state data visible to Google's infrastructure. This is a GenAI anti-pattern where AI-generated analytics implementations often fail to sanitize URLs before sending them to third-party services, causing unintended exposure of user state and authentication data.
Why it might not be a bug
Google Analytics is a legitimate tracking service, but sending sensitive authentication URLs and session data to third parties without user consent violates GDPR and privacy best practices.
Suggested Fix
Implement URL sanitization before sending data to analytics providers. Remove all OAuth state, session IDs, and experience IDs from URLs before logging. Use a sanitization function: sanitize_url(url) { return url.split('?')[0]; } Apply this to all URLs sent to Google Analytics, Google Ads, and third-party services. Additionally, set 'anonymize_ip=true' in Google Analytics configuration and use server-side event tracking instead of client-side URL transmission.
Why Fix
Prevents unintended exposure of authentication state and personal data to third-party analytics providers, complies with GDPR Article 6 (legitimate purpose) and CCPA requirements, reduces insider threat risk from analytics access.
Route To
Privacy/Security Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
N/A - visible in network requestsNetwork:
POST https://pagead2.googlesyndication.com/measurement/conversion?...&url=https%3A%2F%2Fauth.evanscycles.com%2Faccount%2Flogin%3FreturnUrl%3D%252Fconnect%252Fauthorize%252Fcallback%253F... POST https://www.google-analytics.com/g/collect?...&dl=https%3A%2F%2Fauth.evanscycles.com%2Faccount%2Flogin%3FreturnUrl%3D...3
Suspicious obfuscated endpoint path with random-looking characters
CRIT P9
Prompt to Fix
Review the authentication endpoint being called at 'https://auth.evanscycles.com/te72MhG97a2tv_ogJQXv8D67Ocg/hE1iNkYVwE1YQDL9/fQEkCFEB/ZmRUfRx/sTBEB'. This endpoint path contains what appears to be obfuscated or randomly-generated characters. Investigate: (1) What does this endpoint do? (2) Why is it obfuscated? (3) Is this legitimate production code or AI-generated test code that was accidentally deployed? If legitimate, document its purpose and security rationale. If not, replace with a standard, documented API endpoint.
Why it's a bug
Network requests reference an endpoint with an unusual obfuscated path: 'https://auth.evanscycles.com/te72MhG97a2tv_ogJQXv8D67Ocg/hE1iNkYVwE1YQDL9/fQEkCFEB/ZmRUfRx/sTBEB'. This path contains what appears to be random characters, which is a red flag for AI-generated code that may be: (1) improperly hashing/encoding sensitive data, (2) including AI-generated test/placeholder logic, or (3) obfuscating security tokens in URLs where they shouldn't be visible.
Why it might not be a bug
This could be a legitimate obfuscated endpoint if it's part of a deliberate security architecture. However, the randomness and lack of documentation makes this highly suspicious and requires verification.
Suggested Fix
Investigate and document what this endpoint does. If it's handling sensitive operations or tokens, ensure: (1) tokens are never exposed in URL paths, (2) use POST with request bodies instead, (3) implement proper rate limiting, (4) verify this is not AI-generated test/placeholder code that was accidentally deployed. If legitimate, add clear code comments explaining the purpose and security rationale.
Why Fix
Obfuscated endpoints with random-looking paths are a security red flag. Sensitive operations should use standard, documented endpoints with proper authentication mechanisms. This prevents security vulnerabilities and makes code reviewable.
Route To
Security Engineer / Backend Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Network:
POST https://auth.evanscycles.com/te72MhG97a2tv_ogJQXv8D67Ocg/hE1iNkYVwE1YQDL9/fQEkCFEB/ZmRUfRx/sTBEB - Status: 201