C+77%
Quality Score
6
Pages
149
Issues
7.6
Avg Confidence
7.6
Avg Priority
29 Critical91 High28 Medium1 Low
>_ Testers.AI
AI Analysis
Asda scored B (85%) with 149 issues across 6 tested pages, ranking #18 of 22 UK retail sites. That's 25 more than the 123.7 category average (18th percentile).
Top issues to fix immediately: "Content Security Policy Misconfiguration - script-src 'none' with Repo" — (1) Change CSP from report-only to enforcing mode (remove 'report-only'); "Content Security Policy Completely Disabled - script-src 'none' with R" — 1; "Content Security Policy Misconfiguration - All Scripts Blocked Due to " — Immediately audit and fix the CSP header configuration.
Weakest area — accessibility (5/10): Limited visible accessibility features. Color contrast appears adequate but alt text, ARIA labels, and screen reader optimizati...
Quick wins: Enhance accessibility by implementing clear skip navigation links and ensuring ARIA labels are properly applied. Add more descriptive text to promotional banners explaining offers and benefits clearly.
Qualitative Quality
Asda
Category Avg
Best in Category
Pages Tested · 6 screenshots
Homepage
asda.com
asda.com
asda.com
asda.com
asda.com
Detected Issues · 149 total
1
Content Security Policy Misconfiguration - script-src 'none' with Report-Only Mode Allows All Scripts to Load
CRIT P10
Prompt to Fix
We have a critical Content Security Policy misconfiguration in production. The CSP header is set to script-src 'none' in report-only mode, which logs violations but does NOT block scripts. This means malicious scripts can still execute. We need to: (1) Switch CSP from report-only to enforcing mode, (2) Create an explicit whitelist of trusted script sources (OneTrust, Google Tag Manager, Dynamic Yield, Medallia, Adobe DTM, Cloudflare, and internal scripts), (3) Replace inline scripts with nonces or hashes, (4) Add integrity attributes (SRI) to external scripts. The CSP header should look like: Content-Security-Policy: script-src 'self' cdn-ukwest.onetrust.com www.googletagmanager.com cdn-eu.dynamicyield.com resources.digital-cloud.medallia.eu cdn-eu.dynamicyield.com assets.adobedtm.com static.cloudflareinsights.com www.asda.com 'nonce-{random}'. Please implement this fix immediately as it is blocking a critical security vulnerability.
Why it's a bug
The CSP header is configured with script-src 'none' in report-only mode, which means it logs violations but does NOT block malicious scripts. Multiple third-party scripts are loading despite CSP violations (OneTrust, Google Tag Manager, Dynamic Yield, Medallia, Adobe, Cloudflare, etc.). In report-only mode, an attacker can inject arbitrary JavaScript that will execute without being blocked. This is a critical vulnerability because: (1) Third-party scripts can be compromised and inject malware, (2) Attackers can perform XSS attacks that will not be blocked, (3) Session hijacking, credential theft, and sensitive data exfiltration become possible. The CSP is ineffective as a security control.
Why it might not be a bug
The logs indicate this is 'report-only' mode, which is sometimes used for monitoring before enforcement. However, for a production e-commerce site (Asda) handling sensitive customer data and payments, having CSP in report-only mode with script-src 'none' and then allowing all scripts is a dangerous misconfiguration that provides false security.
Suggested Fix
(1) Change CSP from report-only to enforcing mode (remove 'report-only'). (2) Define an explicit whitelist of trusted domains for script-src instead of 'none' (e.g., script-src 'self' cdn-ukwest.onetrust.com www.googletagmanager.com cdn-eu.dynamicyield.com assets.adobedtm.com static.cloudflareinsights.com). (3) Use nonces or hashes for inline scripts instead of allowing them. (4) Implement integrity checks (SRI) for external scripts. (5) Remove or audit all third-party scripts to ensure they are from trusted vendors.
Why Fix
Enforcing a strict CSP with a whitelist of trusted domains is the primary defense against XSS attacks and malicious script injection. This is critical for e-commerce platforms handling customer payment and personal data. Without proper CSP enforcement, attackers can inject keyloggers, steal cookies/tokens, intercept form submissions, or perform credential harvesting.
Route To
Security Engineer / DevOps / Platform Security Team
Page
Tester
Sharon · Security Console Log AnalyzerTechnical Evidence
Console:
[INFO] Loading the script 'https://cdn-ukwest.onetrust.com/scripttemplates/otSDKStub.js' violates the following Content Security Policy directive: "script-src 'none'". The policy is report-only, so the violation has been logged but no further action has been taken.Network:
Multiple script loading violations: OneTrust, Google Tag Manager (GTM-MJ2VMHG), Dynamic Yield, Medallia, Adobe DTM, Cloudflare Insights2
Content Security Policy Completely Disabled - script-src 'none' with Report-Only Mode
CRIT P10
Prompt to Fix
A Content Security Policy is configured with 'script-src 'none'' but is running in report-only mode, which means CSP violations are logged but NOT enforced. This leaves the application vulnerable to XSS and script injection attacks. The following scripts are currently loading despite policy violations: OneTrust, Google Tag Manager, Medallia, Dynamic Yield, Adobe Launch, Cloudflare, and inline scripts. Fix this by: (1) Creating a proper CSP that allows only trusted domains with 'script-src 'self' https://cdn-ukwest.onetrust.com https://www.googletagmanager.com https://resources.digital-cloud.medallia.eu https://cdn-eu.dynamicyield.com https://assets.adobedtm.com https://static.cloudflareinsights.com' (2) Removing report-only mode and enforcing the policy via Content-Security-Policy header (not Content-Security-Policy-Report-Only) (3) Converting inline scripts to external files or adding nonces to required inline scripts (4) Testing the policy in staging before production deployment. This is a critical security issue that must be resolved immediately.
Why it's a bug
The Content Security Policy is set to 'script-src 'none'' in report-only mode, which means it logs violations but does NOT enforce them. This is a critical security misconfiguration that leaves the application completely vulnerable to XSS attacks, malicious script injection, and arbitrary code execution. The policy is supposed to prevent unauthorized scripts from loading, but report-only mode is a development/testing configuration that should never reach production. Multiple third-party scripts (Google Tag Manager, OneTrust, Medallia, Dynamic Yield, Adobe Launch, Cloudflare, etc.) are loading despite the policy violations, indicating zero actual protection. An attacker can inject malicious scripts that will execute without restriction.
Why it might not be a bug
The CSP being in report-only mode could be intentional during a migration or testing phase, but this must not be deployed to production. If this is production code, this is a severe security failure.
Suggested Fix
1. Transition CSP from report-only to enforcement mode by changing the header from 'Content-Security-Policy-Report-Only' to 'Content-Security-Policy'. 2. Update the CSP to use 'script-src 'self'' as a baseline and explicitly whitelist required domains (googleapis.com, cdn-ukwest.onetrust.com, etc.) using full domain allowlists, not wildcards. 3. Replace inline scripts with external script files or use nonces/hashes for required inline scripts. 4. Remove report-only mode entirely once the policy is properly configured and tested in a staging environment. 5. Implement Subresource Integrity (SRI) checks on all external scripts to prevent tampering.
Why Fix
CSP in enforcement mode is a critical defense against XSS and code injection attacks. Without it, attackers can steal session tokens, manipulate page content, harvest user data, perform credential theft, or redirect users to malicious sites. This is a foundational security control that must be properly implemented.
Route To
Security Engineer / DevSecOps / Frontend Security Lead
Page
Tester
Sharon · Security Console Log AnalyzerTechnical Evidence
Console:
[INFO] Loading the script 'https://cdn-ukwest.onetrust.com/scripttemplates/otSDKStub.js' violates the following Content Security Policy directive: "script-src 'none'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. The policy is report-only, so the violation has been logged but no further action has been taken. [INFO] Loading the script 'https://www.googletagmanager.com/gtm.js?id=GTM-MJ2VMHG' violates the following Content Security Policy directive: "script-src 'none'". [INFO] Executing inline script violates the following Content Security Policy directive 'script-src 'none''.Network:
Multiple script loading violations from external domains (OneTrust, Google Tag Manager, Medallia, Dynamic Yield, Adobe Launch, Cloudflare, etc.) all proceeding despite CSP violations.3
Content Security Policy Misconfiguration - All Scripts Blocked Due to script-src 'none'
CRIT P10
Prompt to Fix
Fix critical CSP misconfiguration: The Content-Security-Policy header is set to 'script-src 'none'' which blocks all scripts, but the page loads 40+ legitimate scripts from multiple domains. This is a security misconfiguration. Either update the CSP directive to an allowlist mode with proper sources: 'script-src 'self' https://cdn.asda.com https://www.googletagmanager.com https://cdn-ukwest.onetrust.com ... [add all trusted domains]' and use nonce or hash for inline scripts, OR confirm if report-only mode is intentional and transition to proper enforce mode. Validate with CSP validator tools.
Why it's a bug
CSP header sets 'script-src 'none'' which blocks ALL external and inline scripts, yet the page loads 40+ scripts from various domains (GTM, analytics, monitoring, UI bundles). This is a fundamental security misconfiguration - either the CSP is incorrectly generated/configured, or the policy is set to report-only mode but breaks script functionality. This is a common AI-generated security configuration error where CSP policies are generated without understanding the actual script dependencies.
Why it might not be a bug
The page appears functional despite the CSP violations (report-only mode), and the violations are logged as INFO rather than blocking actual execution. However, the policy creates a false sense of security while actually allowing all scripts to execute, defeating the purpose of CSP.
Suggested Fix
Immediately audit and fix the CSP header configuration. Either: (1) Remove the overly restrictive 'script-src 'none'' directive and replace with proper allowlist including 'self', trusted domains (cdn.asda.com, googletagmanager.com, etc.), and inline script hashes/nonces, OR (2) If intentionally report-only, document why and ensure enforce mode has proper configuration before deploying. Use CSP validation tools to verify the policy matches actual script sources.
Why Fix
CSP is a critical security control. Current misconfiguration creates security theater - it appears strict but actually allows all scripts. This exposes the site to XSS attacks. Correct CSP implementation is essential for production security.
Route To
Security Engineer / DevOps / Backend Infrastructure
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
[INFO] Loading the script 'https://cdn-ukwest.onetrust.com/scripttemplates/otSDKStub.js' violates the following Content Security Policy directive: "script-src 'none'". (40+ instances with various script sources)Network:
CSP Header in HTTP Response