Base44
App Quality Report
Powered by Testers.AI
B-80%
Quality Score
7
Pages
139
Issues
8.1
Avg Confidence
8.1
Avg Priority
65 Critical57 High17 Medium
Testers.AI
>_ Testers.AI AI Analysis

Base44 was tested and 139 issues were detected across the site. The most critical finding was: CORS policy blocks user-details API request. Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (5/10).

Qualitative Quality
Base44
Category Avg
Best in Category
Issue Count by Type
UX
25
Security
25
Content
24
A11y
15
Pages Tested · 7 screenshots
Detected Issues · 139 total
1
CORS policy blocks user-details API request
CRIT P10
Conf 9/10 SecurityOther
Prompt to Fix
Configure server-side CORS for the user details API or route the call through a backend proxy that adds appropriate CORS headers. Ensure the origin (base44.com) is allowed, and verify credentials handling. Add error-handling in the frontend to fall back gracefully if the API is unavailable.
Why it's a bug
A cross-origin request to the user-details endpoint is blocked due to missing CORS headers, breaking authentication/login/user data flows. This is a critical integration issue that often arises in AI-assisted or auto-generated code without proper backend handling.
Why it might not be a bug
If the call is intended to be routed through a secure backend proxy with proper CORS handling, the frontend may be okay. However, the frontend currently attempts a direct cross-origin request, which is inappropriate.
Suggested Fix
Enable Access-Control-Allow-Origin on the server (or proxy via a backend service that injects the correct CORS headers). Validate and scope allowed origins, support credentials if needed, and add retry/error handling on the client with graceful fallbacks.
Why Fix
Restores user login/data flows and prevents blocking UI due to CORS, improving reliability and security.
Route To
Backend Engineer / Platform Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console: [ERROR] Access to XMLHttpRequest at 'https://manage.wix.com/_api/wix-html-login-webapp/user/getUserDetails' from origin 'https://base44.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Network: GET https://manage.wix.com/_api/wix-html-login-webapp/user/getUserDetails
2
Device fingerprinting data exposed in telemetry POST
CRIT P9
Conf 9/10 Other
Prompt to Fix
In the telemetry POST to frog.wix.com/bolt-performance, remove or redact the infoInitialZoom field and any devicePixelRatio, innerWidth, outerWidth, and visualViewportScale data. Implement a consent-gated, privacy-preserving analytics mode that reports only high-level metrics (e.g., viewport segments, not exact pixel values).
Why it's a bug
The telemtry POST to frog.wix.com/bolt-performance includes device fingerprinting data such as devicePixelRatio, innerWidth, outerWidth, and visualViewportScale (infoInitialZoom). These values are highly unique to a user’s device and can enable cross-site fingerprinting and user profiling without explicit consent.
Why it might not be a bug
Some telemetry requires device context for performance/UX analytics; however, this should be minimized and consent-gated to reduce fingerprinting risk.
Suggested Fix
Remove or mask device fingerprint fields from the telemetry payload (e.g., send only coarse or hashed values, or aggregate metrics). Gate collection behind explicit user consent and provide a privacy-friendly analytics mode that excludes precise screen dimensions and pixel ratio.
Why Fix
Mitigates device fingerprinting risk, reduces cross-site tracking potential, and aligns with data minimization principles.
Route To
Frontend/Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console: POTENTIAL ISSUE: Tracking request detected
Network: POST https://frog.wix.com/bolt-performance?src=19&_brandId=studio...&infoInitialZoom=%7B%22devicePixelRatio%22%3A1%2C%22innerWidth%22%3A1920%2C%22outerWidth%22%3A756%2C%22visualViewportScale%22%3A1%7D&mpaSessionId=...
3
Session identifiers exposed in URL query parameters during frog.wix.com bolt-performance requests
CRIT P9
Conf 9/10 SecurityOther
Prompt to Fix
In the code that calls https://frog.wix.com/bolt-performance, remove sensitive identifiers from the URL query string. Send them in the request body or in a secure Authorization header instead. Example: POST to https://frog.wix.com/bolt-performance with header Authorization: Bearer <token> and body { "src":72, "evid":21, "session_id": "<REDACTED>", "mpaSessionId": "<REDACTED>" }. Ensure server accepts token in header/body, disable tokens in URL, and implement CSRF protections, HttpOnly Secure cookies, and log redaction. Review logs to ensure no sensitive fields appear in URLs or referer headers.
Why it's a bug
URLs in a POST request to https://frog.wix.com/bolt-performance include session_id and mpaSessionId in the query string. These tokens can be logged by servers, captured in browser history, or leaked via referer headers, enabling session hijacking or replay attacks if they are used for authentication or session management.
Why it might not be a bug
If these identifiers are strictly telemetry IDs and not security tokens, risk is lower, but their presence in URLs is against security best practices and could still lead to exposure through logs and history.
Suggested Fix
Do not send session-related tokens in URL query parameters. Move sensitive identifiers to the request body or to a secure Authorization header. Use HttpOnly and Secure cookies for session management, enable CSRF protections on state-changing requests, rotate tokens, and redact sensitive fields in logs. Audit telemetry endpoints to ensure URLs do not contain sensitive data.
Why Fix
Eliminates leakage of session-related tokens via logs, caches, and referer headers, reducing risk of session hijacking and replay attacks. Aligns with secure session and API design best practices.
Route To
Security Engineer / Backend Engineer
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Console: Observed: POST to frog.wix.com/bolt-performance includes session_id and mpaSessionId in URL query parameters.
Network: POST https://frog.wix.com/bolt-performance?src=72&evid=21&appName=wix-studio&is_rollout=0&is_company_network=false&is_sav_rollout=0&is_dac_rollout=0&dc=uw2-pub-1&microPop=fastly_sea1_g&is_cached=true&msid=deeec5de-0fad-46a5-8431-2bd44d0ef6a1&session_id=8b7a3cef-a4e3-4b3f-8d0e-2a48d8fb7d32&ish=true&isb=true&isbr=webdriver&vsi=7cda95ee-98c9-4ee0-9967-cdd2ba2f39ea&caching=hit,hit_miss&pv=visible&pn=1&v=1.17075.0&url=https%3A%2F%2Fbase44.com%2F&st=1&ts=243&tsn=453&platformOnSite=true&hasInitialZoom=false&infoInitialZoom=%7B%22devicePixelRatio%22%3A1%2C%22innerWidth%22%3A1920%2C%22outerWidth%22%3A756%2C%22visualViewportScale%22%3A1%7D&mpaSessionId=b08b0c8b-b8c0-44fd-b43d-7d73e398ceca
+48
48 more issues detected  View all →
PII in tracking request URL (session_id and msid exposed)
Client-side Wix API call blocked by CORS (Access-Control-All...
Third-party data sharing detected with frog.wix.com in base4...
and 45 more...
Unlock All 139 Issues
You're viewing the top 3 issues for Base44.
Sign up at Testers.AI to access the full report with all 139 detected issues, detailed fixes, and continuous monitoring.
Sign Up at Testers.AI or let us run the tests for you