B86%
Quality Score
5
Pages
76
Issues
8.1
Avg Confidence
7.9
Avg Priority
37 Critical25 High14 Medium
>_ Testers.AI
AI Analysis
Lmsdev.Mymokxa was tested and 76 issues were detected across the site. The most critical finding was: CSRF token exposed in console logs. Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).
Qualitative Quality
Lmsdev.Mymokxa
Category Avg
Best in Category
Pages Tested · 5 screenshots
Homepage
lmsdev.mymokxa.com.jw
lmsdev.mymokxa.com.jw
lmsdev.mymokxa.com.jw
lmsdev.mymokxa.com.jw
Detected Issues · 76 total
1
CSRF token exposed in console logs
CRIT P9
Prompt to Fix
Identify code path that logs the CSRF token to the console and remove the logging of the actual token. Replace with redacted token or mask. Ensure no code path prints the token value to console in any environment. Add a development-only safe-logging flag and ensure production logs are free of secrets. Verify that CSRF tokens are not exposed in DOM, URLs, or error messages.
Why it's a bug
A CSRF token is sensitive session-related data. Logging the master CSRF token to the browser console exposes it to users and potential attackers, enabling token leakage and increasing the risk of CSRF exploitation. Tokens should never be logged or exposed in client-side logs.
Suggested Fix
Remove or mask the CSRF token from all console logs. Do not print token values in code paths or error messages. If debugging is required, replace token values with redacted placeholders (e.g., CSRF_TOKEN_REDACTED) and ensure verbose logging is disabled in production. Implement a log redaction utility and enforce it server-side or in the frontend build.
Why Fix
Prevent leakage of CSRF tokens to the client or to logs, reducing risk of token theft and potential CSRF attacks or session hijacking.
Route To
Frontend Security Engineer
Page
Tester
Sharon · Security Console Log Analyzer
Technical Evidence
Console:
[DEBUG] Master token [OWASP-CSRFTOKEN]: LIVU-51NO-XGQ7-D41U-TLUK-WZ2M-0L14-2RE42
Unconsented third-party analytics (Cloudflare) beacons and RUM integration
CRIT P9
Prompt to Fix
In the frontend initialization flow, wrap all Cloudflare analytics calls with a consent check. Do not load https://static.cloudflareinsights.com/beacon.min.js/... or execute POST to https://lmsdev.mymokxa.com/cdn-cgi/rum? unless the user has consented to analytics cookies. Implement a consent banner that records user choice and loads a privacy-preserving analytics module only when allowed. Configure Cloudflare RUM to anonymize IP addresses and minimize data collection (disable sending of personally identifiable information). Remove unconditional calls and gate them behind consent. Update CSP to restrict third-party tracking and document data-sharing practices in the privacy policy.
Why it's a bug
The application loads Cloudflare analytics beacons (beacon.min.js) and Cloudflare RUM endpoints (cdn-cgi/rum) without any visible user consent gating. These calls reach third-party services and can collect device, network, and usage data, enabling cross-site tracking. There is no evidence in the logs of a consent check or privacy banner gating these calls.
Why it might not be a bug
If explicit user consent mechanisms exist elsewhere (privacy/cookie banner) or if data collection is strictly minimal and consented, this would be less concerning. The logs provided do not show evidence of consent gating, so the default assumption is risk.
Suggested Fix
Introduce a privacy-consent gate for analytics: load Cloudflare beacon and RUM scripts only after the user has given consent (e.g., via a cookies/cprivacy banner). Consider configuring analytics to anonymize IP addresses, minimize data collection, or switch to a privacy-preserving/first-party analytics solution. Add an opt-out option and ensure privacy policy clearly discloses data sharing with third parties.
Why Fix
Reducing third-party data sharing and ensuring consent protects regulatory compliance (GDPR/CCPA) and preserves user trust. It also minimizes potential data leakage from analytics scripts.
Route To
Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Network:
GET https://static.cloudflareinsights.com/beacon.min.js/v8c78df7c7c0f484497ecbca7046644da1771523124516; POST https://lmsdev.mymokxa.com/cdn-cgi/rum?3
Exposure of Development Environment Subdomain in Public Traffic
CRIT P9
Prompt to Fix
Action: Replace all occurrences of the development host in public code and infrastructure with the production host. Implement production-only DNS and firewall rules to block lmsdev.* from internet access. Update API base URLs to https://lms.mymokxa.com (production). Remove dev endpoints from public swagger/docs and hide behind authentication. Add a strict WAF and rate-limiting for sensitive endpoints. Ensure TLS and HSTS; Ensure all cookies have Secure, HttpOnly, SameSite; Add CSP headers. After changes, verify no public requests to lmsdev.mymokxa.com remain and scan logs for any leakage.
Why it's a bug
The request URLs reveal a development subdomain (lmsdev.mymokxa.com). If this domain is reachable from the public internet, it exposes internal staging endpoints, configuration, and potentially incomplete security hardening, increasing attack surface and facilitating targeted reconnaissance.
Why it might not be a bug
If the dev subdomain is strictly sandboxed behind VPN or private network with no public exposure, this is not a vulnerability; however, the observed traffic indicates public exposure. Recommend confirm exposure boundaries; if isolated, this is a non-issue.
Suggested Fix
Move all production traffic to the production domain, remove or disable the lmsdev subdomain from public DNS, implement network access controls (allowlists or VPN), ensure dev endpoints are not publicly reachable, and enforce TLS with valid certificates. Update frontend/backend base URLs to production host. Optionally implement WAF rules and CSRF protections for state-changing endpoints.
Why Fix
Eliminating dev environment exposure reduces information leakage, lowers risk of exploiting non-production code, and aligns with secure deployment practices; improves attack surface and trust.
Route To
Security Engineer / Platform (DevOps)
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Console:
Dev subdomain observed in request URLs: lmsdev.mymokxa.com, indicating development environment traffic.Network:
GET https://lmsdev.mymokxa.com/jw/web/userview/lms/v/_ - Status: N/A