B+87%
Quality Score
5
Pages
105
Issues
7.7
Avg Confidence
7.8
Avg Priority
26 Critical65 High14 Medium
>_ Testers.AI
AI Analysis
Ebuyer scored B+ (87%) with 105 issues across 6 tested pages, ranking #6 of 20 UK retail sites. That's 25 fewer than the 130.2 category average (75th percentile).
Top issues to fix immediately: "Missing Cache Headers on All Static Assets (CSS, JS, Fonts, Images)" — Add Cache-Control headers to all static assets: (1) For versioned/hashed assets (with content hash in filename like 2026; "Critical Missing Cache Headers on All Static Assets and Third-Party Re" — 1) Add Cache-Control headers to all static assets: For versioned assets (with query params like ?v=; "Multiple broken resource loads causing visual degradation" — Investigate and resolve the DNS resolution failures (ERR_NAME_NOT_RESOLVED).
Weakest area — accessibility (5/10): Contrast ratios appear adequate in places but may struggle in others.
Quick wins: Add skip-to-content links and improve keyboard navigation for better accessibility. Implement clearer visual hierarchy to reduce cognitive load and guide user attention.
Qualitative Quality
Ebuyer
Category Avg
Best in Category
Pages Tested · 5 screenshots
Homepage
ebuyer.com
ebuyer.com
ebuyer.com
ebuyer.com
Detected Issues · 105 total
1
Sensitive State Data Exposed in URL Parameters
CRIT P9
Prompt to Fix
The OAuth authorization redirect is exposing sensitive information (order history URLs, session IDs, experience IDs) in URL parameters. This is a security and privacy issue. Refactor the authentication flow to: 1) Generate a random opaque state token instead of encoding the return URL, 2) Store the actual return URL server-side in a session with short TTL, 3) Move session_id, experience_id, and anonymous_id from URL parameters to secure HttpOnly cookies, 4) Validate the state token matches the stored value during callback. Ensure this follows OAuth 2.0 security best practices and doesn't expose any sensitive user data in URLs or logs.
Why it's a bug
Multiple network calls expose sensitive state information in URL parameters, including 'session_id', 'experience_id', 'anonymous_id', and base64-encoded 'state' parameters containing the full return URL with order history information. This is characteristic of AI-generated authentication code that lacks proper understanding of OAuth security best practices. Sensitive identifiers and state data in URLs can be: (1) logged in server logs, (2) exposed in browser history, (3) leaked via Referer headers, (4) visible in HTTP access logs. The state parameter appears to be base64-encoded but not properly encrypted.
Why it might not be a bug
OAuth 2.0 does use state parameters in URLs by design for CSRF protection. However, the state parameter should be a random, opaque token that doesn't contain the actual return URL. The current implementation encodes the sensitive return URL directly in the state parameter, which is an anti-pattern.
Suggested Fix
Implement proper OAuth 2.0 state handling: (1) Generate a cryptographically random opaque state token (not base64-encoded sensitive data), (2) Store the return URL securely server-side in a session/cache with a short TTL, (3) Map the state token to the stored return URL on callback, (4) Validate state parameter matches stored value, (5) Remove session_id, experience_id, and anonymous_id from URL parameters - store these in secure, HttpOnly cookies instead.
Why Fix
Exposing sensitive state data in URLs violates OAuth security best practices and privacy regulations (GDPR, CCPA). This could enable: session hijacking, tracking user behavior, man-in-the-middle attacks, and unauthorized access to user order history. Proper state handling is fundamental to secure authentication.
Route To
Security Engineer / Backend Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
Network activity shows: state=eyJhIjoiMCIsIm4iOiJrSk9RVkw1MSIsInIiOiJodHRwczovL3d3dy5lYnV5ZXIuY29tL2FjY291bnRpbmZvcm1hdGlvbi9vcmRlcmhpc3RvcnlzdW1tYXJ5In0%3D containing encoded order history pathNetwork:
GET https://auth.ebuyer.com/connect/authorize?client_id=38535099dd23478aa1011b9742d4a47e&response_type=code&scope=openid%20offline_access%20email%20email&redirect_uri=https%3A%2F%2Fwww.ebuyer.com%2Fauth-callback&state=eyJhIjoiMCIsIm4iOiJrSk9RVkw1MSIsInIiOiJodHRwczovL3d3dy5lYnV5ZXIuY29tL2FjY291bnRpbmZvcm1hdGlvbi9vcmRlcmhpc3RvcnlzdW1tYXJ5In0%3D&prompt=login&anonymous_id=164a367c-6b0a-4572-b6d5-21f8ea1310c3&session_id=fea5f544-5d79-48df-bda0-eb263c94d2c1&experience_id=e93e1f7f-8f8e-4f1b-bc51-99dbac05009b2
Missing Cache Headers on All Static Assets (CSS, JS, Fonts, Images)
CRIT P10
Prompt to Fix
All static assets on ebuyer.com are missing Cache-Control headers. Add proper caching headers to improve repeat visit performance: For versioned/hashed assets (identified by hash in filename, e.g., dist/2026.03.06.5/, _next/static files with hash), set 'Cache-Control: public, max-age=31536000, immutable' to cache for 1 year since content never changes. For images and fonts without version hashes, set 'Cache-Control: public, max-age=86400' for 24 hours. Add ETag headers to all static assets. Configure your web server (nginx/Apache) or CDN to set these headers. Test by checking response headers for CSS, JS, fonts, and images - they should return Cache-Control headers and 304 Not Modified on repeat requests.
Why it's a bug
Every single static resource returned 200 status codes without proper Cache-Control headers. This includes: CSS files (global.css, main.css, home.css, and multiple Next.js CSS files), JavaScript bundles (global-header.js, algolia-search.js, footer scripts), web fonts (Roboto-Regular.woff2, Lato fonts, Averta fonts), images from CDN, and brand logos. Without caching headers, browsers re-download these unchanged resources on every page visit, wasting bandwidth and causing slow repeat visits. Users on repeat visits should see 304 Not Modified responses, but instead receive full 200 responses.
Why it might not be a bug
If assets change very frequently, aggressive caching could show stale content to users.
Suggested Fix
Add Cache-Control headers to all static assets: (1) For versioned/hashed assets (with content hash in filename like 2026.03.06.5 or f2d00db9d8db7dd7.css), use 'Cache-Control: public, max-age=31536000, immutable' (1 year); (2) For non-versioned assets like unversioned images, use 'Cache-Control: public, max-age=86400' (24 hours); (3) Add ETag headers for all assets to enable 304 Not Modified responses; (4) Use far-future expires headers for versioned assets.
Why Fix
Proper caching transforms repeat visit performance. Instead of downloading 50+ assets on every visit, users get instant page loads from browser cache. This dramatically reduces bandwidth costs, improves page load speed from days 2+, boosts Core Web Vitals on repeat visits, and reduces server load. Essential for mobile users and users on slow connections.
Route To
DevOps Engineer / Web Infrastructure Engineer / Backend Engineer managing CDN configuration
Page
Tester
Tariq · Performance SpecialistTechnical Evidence
Network:
GET https://www.ebuyer.com/_next/static/css/2e407863a85520b5.css - Status: 200 ⚠️ MISSING CACHE HEADERS3
Critical Missing Cache Headers on All Static Assets and Third-Party Resources
CRIT P10
Prompt to Fix
Configure the web server (likely IIS or nginx) to add Cache-Control headers to all static assets. For auth.ebuyer.com: 1) Set 'Cache-Control: public, max-age=31536000, immutable' for versioned CSS/JS files (those with ?v= query parameters) since version changes indicate new content. 2) Set 'Cache-Control: public, max-age=86400' for font files (.woff2). 3) Set 'Cache-Control: public, max-age=604800' for SVG image assets. 4) Add ETag headers using strong validators (file hash). 5) Configure gzip compression in response headers. 6) Test with curl to verify Cache-Control headers are present: 'curl -I https://auth.ebuyer.com/css/base.css' should show 'Cache-Control' header.
Why it's a bug
The network activity shows that virtually ALL static resources are missing Cache-Control and other cache headers: CSS files (base.css, loginv2.css, ebuy.css, inputsv2.css), JavaScript files (jquery, validation libraries, main.js), font files (Roboto woff2), SVG images, and even third-party resources from Google (reCAPTCHA scripts, styles, images). This means every time a user visits the login page, the browser downloads all these resources again instead of using cached copies. For repeat visitors and users with poor connections, this significantly increases load time. The note '⚠️ MISSING CACHE HEADERS' appears on nearly every successful resource request.
Why it might not be a bug
Some third-party resources (Google reCAPTCHA) may be intentionally not cached to ensure security updates, but auth domain resources (fonts, CSS, JS, SVGs) absolutely should have cache headers.
Suggested Fix
1) Add Cache-Control headers to all static assets: For versioned assets (with query params like ?v=...), use 'Cache-Control: public, max-age=31536000' (1 year) since the version hash changes on updates. 2) For index/entry pages, use 'Cache-Control: public, max-age=3600' or no-cache with ETag. 3) Add Expires headers as fallback for older clients. 4) Implement ETag headers for all resources to enable 304 Not Modified responses. 5) Configure server to serve gzip/brotli compressed versions with proper cache headers. 6) Consider using Content Delivery Network (CDN) with proper cache control.
Why Fix
Proper caching headers reduce bandwidth usage, decrease page load time for repeat visitors by 50-80%, improve Core Web Vitals metrics, and reduce server load. For login pages that users visit frequently, this is particularly impactful. Missing cache headers forces unnecessary re-downloads of identical resources, wasting bandwidth and degrading performance.
Route To
DevOps Engineer / Backend Infrastructure Engineer
Page
Tester
Tariq · Performance SpecialistTechnical Evidence
Network:
GET https://auth.ebuyer.com/fonts/Roboto-Regular.woff2 - Status: 200 ⚠️ MISSING CACHE HEADERS, GET https://auth.ebuyer.com/css/base.css - Status: 200 ⚠️ MISSING CACHE HEADERS, GET https://www.google.com/recaptcha/api.js - Status: 200 ⚠️ MISSING CACHE HEADERS