B84%
Quality Score
6
Pages
121
Issues
7.4
Avg Confidence
7.8
Avg Priority
31 Critical75 High15 Medium
>_ Testers.AI
AI Analysis
Culture Kings scored B (84%) with 121 issues across 6 tested pages, ranking #7 of 14 US retail sites. That's 16 more than the 105.1 category average (50th percentile).
Top issues to fix immediately: "Modal Dialog Blocks Primary Content Without Clear Dismiss Mechanism" — Add a clearly visible close button (X icon) in the top-right corner of the modal dialog; "Multiple DNS resolution failures - ERR_NAME_NOT_RESOLVED" — 1) Identify which domains are failing to resolve by checking the Network tab in DevTools; "Multiple images with generic or missing alt text reduce accessibility " — Audit all images on the page and provide meaningful, descriptive alt text for informative images.
Weakest area — accessibility (5/10): Significant accessibility issues including low contrast text on dark backgrounds, unclear alt text for product images, and navi...
Quick wins: Improve color contrast ratios throughout the site to meet WCAG AA standards, especially for body text on dark.... Add descriptive alt text to all product images and ensure semantic HTML structure for screen readers.
Qualitative Quality
Culture Kings
Category Avg
Best in Category
Pages Tested · 6 screenshots
Homepage
culturekings.com.au
culturekings.com.au
culturekings.com.au
culturekings.com.au
culturekings.com.au
Detected Issues · 121 total
1
Early Page-Load AI/LLM Calls Without User Consent or Defer
CRIT P9
Prompt to Fix
We're calling edge.personalizer.io and monorail-edge.shopifysvc.com immediately on page load without user consent or deferring until after page render. This violates privacy best practices and degrades performance. Please: 1) Implement a DeferredAIServiceLoader that queues AI API calls until after page interactive, 2) Add user consent checks before invoking any personalization or analytics AI endpoints, 3) Use RequestIdleCallback or setTimeout to push these calls to after initial render, and 4) Ensure no AI data is sent until the user has had a chance to opt-in or the page is fully interactive.
Why it's a bug
The network activity shows multiple AI/LLM endpoint calls firing on initial page load without any user interaction or consent: edge.personalizer.io (personalization engine), monorail-edge.shopifysvc.com/unstable/produce_batch (Shopify analytics with potential AI components), and config-security.com/first. These are being invoked during the critical rendering path, causing unnecessary token bloat and privacy concerns. AI services should be lazy-loaded only when needed, not on every page visit.
Why it might not be a bug
These might be necessary for initial personalization. However, the timing and lack of consent mechanisms suggest they could be deferred to after page render or user interaction.
Suggested Fix
Defer all non-critical AI/LLM API calls to after the page has finished rendering and user has interacted with the page. Implement lazy-loading for personalization features. Add user consent checks before invoking any third-party AI services. Use Intersection Observer or other deferred loading patterns for AI-powered features rather than blocking page load.
Why Fix
Early AI API calls on page load contribute to slower Time to Interactive (TTI), increased bandwidth consumption, and privacy violations by sending user data to third-party AI services without explicit opt-in. This is especially problematic for users in privacy-conscious regions (GDPR, etc.).
Route To
Frontend Performance Engineer, Privacy/Compliance Officer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
[LOG] [FloatingWidget] continue legacy widget flowNetwork:
GET https://edge.personalizer.io/storefront/2.0.0/js/shopify/storefront.min.js - Status: 200 (fires on initial page load), POST https://monorail-edge.shopifysvc.com/unstable/produce_batch - Status: N/A2
API Key Exposure in Personalizer Service URL Parameters
CRIT P9
Prompt to Fix
We are loading the personalizer.io storefront library with an API key exposed in the URL query parameter: key=bpybl-z2aht7u5glt8snw4jkw-ojruj. This key appears in browser logs, server logs, and referrer headers. Create a server-side proxy endpoint that accepts requests to /api/personalizer and forwards them to edge.personalizer.io, attaching the API key in the Authorization header instead of the URL. Update all JavaScript references to load from the proxy endpoint without the key parameter. Immediately rotate the exposed API key in the personalizer.io dashboard.
Why it's a bug
The personalizer.io service is being loaded with an API key visible in the URL query parameters: 'key=bpybl-z2aht7u5glt8snw4jkw-ojruj'. This API key appears in multiple network requests and is transmitted in plain text as a URL parameter. Browser history, proxy logs, server logs, and referrer headers will capture this key, allowing unauthorized parties to make requests on behalf of Culture Kings and access personalization data or manipulate user experiences.
Why it might not be a bug
The key may be intentionally public-facing or read-only scoped, and personalizer.io may be a third-party service with its own security model. However, best practice dictates avoiding any credentials in URLs regardless of scope.
Suggested Fix
Move the API key from URL parameters to a secure authentication header (Authorization or custom header). If personalizer.io requires URL-based authentication, implement a server-side proxy that accepts requests without the key and forwards them with the key in a header or request body. Rotate the exposed key immediately.
Why Fix
Removing credentials from URLs prevents accidental exposure through browser history, logs, referrer headers, and proxy capture. This is a fundamental security best practice that protects against unauthorized API access and data compromise.
Route To
Backend/API Security Engineer
Page
Tester
Sharon · Security Networking AnalyzerTechnical Evidence
Network:
GET https://edge.personalizer.io/storefront/2.0.0/js/shopify/storefront.min.js?key=bpybl-z2aht7u5glt8snw4jkw-ojruj&shop=culture-kings-2.myshopify.com3
API Key Exposed in Third-Party Personalization Service URL
CRIT P9
Prompt to Fix
We have discovered that the Culture Kings Shopify store is exposing an API key 'bpybl-z2aht7u5glt8snw4jkw-ojruj' in plain text within URL query parameters for requests to edge.personalizer.io. This key appears in multiple network requests: GET https://edge.personalizer.io/storefront/2.0.0/js/shopify/storefront.min.js?key=bpybl-z2aht7u5glt8snw4jkw-ojruj&shop=culture-kings-2.myshopify.com. Please implement a server-side proxy endpoint on the Culture Kings backend that handles all personalization requests internally, passing the API key in secure backend-to-backend communication instead of exposing it to the client. Alternatively, if the key must remain client-side, immediately rotate the current key, create a new restricted-scope key with minimal permissions, and implement monitoring to detect any suspicious activity on the personalizer.io service account.
Why it's a bug
The personalizer.io service requests contain an exposed API key 'bpybl-z2aht7u5glt8snw4jkw-ojruj' visible in plain text within the URL query parameters. This key is transmitted across multiple requests to edge.personalizer.io and appears in browser network logs, potentially accessible to anyone with access to the page source, network inspector, or browser history. If this key is compromised, attackers could impersonate the Culture Kings store and manipulate personalization behavior or access customer data.
Why it might not be a bug
The requests are over HTTPS, which provides encryption in transit. The key may be intended to be semi-public if it's a client-side personalization service without sensitive operations. However, even client-side keys should be rotated regularly and monitored for misuse.
Suggested Fix
1) Implement server-side proxy for personalizer.io requests to avoid exposing the API key in client-side URLs. 2) If client-side key exposure is unavoidable, use a restricted key with minimal permissions scope. 3) Implement key rotation policies and monitor for unusual activity on the personalizer.io account. 4) Consider using environment-based key injection rather than hardcoded URLs.
Why Fix
Exposed API keys are a critical vulnerability that enables account takeover and unauthorized access to customer personalization data. Attackers could modify product recommendations, inject malicious content, or exfiltrate customer behavior data. Fixing this prevents credential compromise and protects customer data integrity.
Route To
Backend/Security Engineer
Page
Tester
Sharon · Security Networking AnalyzerTechnical Evidence
Console:
Network request showing query parameter exposureNetwork:
GET https://edge.personalizer.io/storefront/2.0.0/js/shopify/storefront.min.js?key=bpybl-z2aht7u5glt8snw4jkw-ojruj&shop=culture-kings-2.myshopify.com