B84%
Quality Score
7
Pages
98
Issues
7.9
Avg Confidence
7.8
Avg Priority
37 Critical43 High18 Medium
>_ Testers.AI
AI Analysis
WhatsApp was tested and 98 issues were detected across the site. The most critical finding was: AI/LLM endpoints invoked on page load (no user interaction/consent). Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (6/10).
Qualitative Quality
WhatsApp
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
www.whatsapp.com
www.whatsapp.com
www.whatsapp.com
www.whatsapp.com
www.whatsapp.com
www.whatsapp.com
Detected Issues · 98 total
1
AI/LLM endpoints invoked on page load (no user interaction/consent)
CRIT P10
Prompt to Fix
Identify all AI/LLM related network requests that run on initial page load. Remove or defer them behind user interaction or a consent flow. Introduce a feature flag (enableAI) to control preloading. Ensure prompts/data used for AI calls are minimized, consent is shown, and there is no data leakage on first paint.
Why it's a bug
Console indicates AI/LLM endpoints are detected and multiple requests appear to be made, implying AI-related calls occur during initial page paint. This can raise privacy concerns, increase load times, and incur unnecessary token/data usage without explicit user consent or interaction.
Why it might not be a bug
Some apps preload AI contexts for faster responses; if clearly intended and consented, this may be acceptable. However, absence of visible consent or controls makes it risky.
Suggested Fix
Move all AI/LLM calls behind explicit user interaction or a clear consent prompt. Implement lazy-loading with proper feature flags, add a non-blocking loading indicator, and consider batching or limiting payloads. Audit endpoints for privacy implications and remove any hard preloads unless required and disclosed.
Why Fix
Prevent potential privacy issues, reduce unnecessary network traffic, and improve perceived performance by avoiding AI calls before user intent is known.
Route To
Frontend/Performance Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTEDNetwork:
GET https://www.whatsapp.com/ajax/bz?... (AI-related endpoint usage inferred from console log)2
Authentication tokens exposed in URL query parameters during WhatsApp AJAX POST
CRIT P9
Prompt to Fix
Frontend and API teams: Remove sensitive session/auth tokens from all URLs. Change AJAX requests to transmit tokens via Authorization header or request body. Implement CSRF tokens for state-changing POSTs, enforce Origin checks, and ensure cookies use SameSite, Secure, and HttpOnly flags. Deploy server-side logs masking for query parameters that look like session tokens.
Why it's a bug
The POST request to https://www.whatsapp.com/ajax/bz includes authentication/session related tokens and dynamic parameters in the URL query string (e.g., __a, __dyn, __hs, __hsi, __req, __rev, __s, __user). Such tokens can be logged in browser history, server logs, referer headers, or analytics services, leading to potential session hijacking, replay attacks, or CSRF risk.
Why it might not be a bug
If these tokens are strictly ephemeral, single-use, and never logged or exposed in headers/logs, risk is reduced. However, their presence in the URL still creates an exposure surface and is considered poor practice.
Suggested Fix
Move sensitive tokens out of the URL. Pass authentication/session tokens in HTTP headers (Authorization: Bearer <token>) or in the request body for POST requests. Avoid placing sensitive state in query parameters. Ensure TLS is enforced, set Secure and HttpOnly flags on cookies, and implement proper CSRF protections.
Why Fix
Prevent leakage of tokens via browser history, logs, and referer headers, reducing risk of session hijacking and replay attacks.
Route To
Security Engineer, Backend/API Developer
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Console:
POST https://www.whatsapp.com/ajax/bz?__a=1&__ccg=UNKNOWN&__dyn=7xe6E5aQ1PyUbFp41twpUnwgU6C7UW1DxW0SU1nEhw2nVE4W0qa0FE2aw7Bx61vw5zw78w5Uwdq0Ho2ewnE0Ca0h-0Lo6-0uS0ue0rq&__hs=20538.BP%3Awhatsapp_www_pkg.2.0...0&__hsi=7621477186936167056&__req=1&__rev=1036008164&__s=hmdbcz%3Awa8enh%3Aqvjn6z&__user=0&dpr=1&jazoest=22306&lsd=AdQQj-z19G2iUtsBtnDJPqmV3pINetwork:
POST https://www.whatsapp.com/ajax/bz?__a=1&__ccg=UNKNOWN&__dyn=7xe6E5aQ1PyUbFp41twpUnwgU6C7UW1DxW0SU1nEhw2nVE4W0qa0FE2aw7Bx61vw5zw78w5Uwdq0Ho2ewnE0Ca0h-0Lo6-0uS0ue0rq&__hs=20538.BP%3Awhatsapp_www_pkg.2.0...0&__hsi=7621477186936167056&__req=1&__rev=1036008164&__s=hmdbcz%3Awa8enh%3Aqvjn6z&__user=0&dpr=1&jazoest=22306&lsd=AdQQj-z19G2iUtsBtnDJPqmV3pI3
Exposure of tracking identifiers in asset URLs enabling cross-site tracking
CRIT P9
Prompt to Fix
In the asset request URLs to scontent.whatsapp.net, remove all _nc_* query parameters (gid, ohc, oc, ss, ht, sid) from image fetch URLs. Replace per-request identifiers with cookies or server-side session IDs and ensure that no unique user/session data is leaked in URL strings. If analytics are required, implement opt-in, on-site privacy notices, and use a first-party analytics endpoint with consent, logging data server-side rather than in URL parameters.
Why it's a bug
Asset requests to scontent.whatsapp.net include tracking query parameters such as _nc_gid, _nc_ohc, _nc_sid, _nc_ht in the URL. These appear to be unique identifiers that can be used to correlate user sessions across sites. This constitutes potential cross-site tracking and user profiling without explicit user consent. No visible consent indicators accompany these requests.
Why it might not be a bug
CDNs sometimes append internal identifiers for caching or debugging; if these identifiers rotate per session and are not linked to personal data, privacy risk is lower. However, their persistent presence in URLs across many requests suggests potential cross-site tracking capability.
Suggested Fix
Remove or obfuscate all tracking-related query parameters from asset URLs (for example, stop appending _nc_* params to scontent.whatsapp.net resource URLs). If tracking is needed for analytics, move to server-side measurement with opt-in consent and use cookies on a first-party basis rather than URL parameters. Implement privacy-preserving CDN configurations and ensure a clear privacy notice.
Why Fix
Eliminating user/session identifiers in URL query strings reduces cross-site tracking risk, improves user privacy, and helps with regulatory compliance and user trust.
Route To
Privacy Engineer / Web Platform Security
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Network:
GET https://scontent.whatsapp.net/v/t39.8562-34/472902085_9036161936482175_1983222485176306165_n.png?stp=dst-webp&ccb=1-7&_nc_sid=73b08c&_nc_ohc=Z_v0LmIaUgAQ7kNvwEg1y_b&_nc_oc=Adpgsog6mhHAOi8ssNprWjubwyTjfaf_kvSNIb_qi1cvlDxQa1akSbMFD7OtE7ofVvM&_nc_zt=3&_nc_ht=scontent.whatsapp.net&_nc_gid=EvaoO9FCsO24bJwEKd7wQg&_nc_ss=7a30f&oh=01_Q5Aa4AFzabf1k_7cX2w3OTqIcmLnvlIjpZL6YvpHKWiUgWlvhQ&oe=69CAAF1C