B83%
Quality Score
7
Pages
103
Issues
7.9
Avg Confidence
7.7
Avg Priority
39 Critical42 High21 Medium1 Low
>_ Testers.AI
AI Analysis
Baidu was tested and 103 issues were detected across the site. The most critical finding was: Analytics requests leak login state via isLogin parameter. Issues span Security, Legal, A11y, Performance categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).
Qualitative Quality
Baidu
Category Avg
Best in Category
Pages Tested Β· 7 screenshots
Homepage
www.baidu.com
www.baidu.com
www.baidu.com
www.baidu.com
www.baidu.com
www.baidu.com
Detected Issues Β· 103 total
1
Analytics requests leak login state via isLogin parameter
CRIT P9
Prompt to Fix
Analyze the analytics integration on the client side and remove any exposing login-state data from outgoing tracking requests. Replace isLogin parameter with a consent-guarded, non-identifying metric payload. If login state is necessary for server-side analytics, derive a per-session anonymous_id stored in a secure cookie and transmit only that anonymized ID to external endpoints. Implement a user consent check prior to any analytics call.
Why it's a bug
Multiple analytics-like requests (sp1.baidu.com/v.gif and sp2.baidu.com/v.gif) include login state indicator isLogin=0, which reveals whether the user is logged in to third-party analytics endpoints. This constitutes unconsented disclosure of authentication status and enables cross-site/user tracking.
Why it might not be a bug
Some analytics implementations require login state to tailor metrics; however, transmitting isLogin to external endpoints without explicit user consent or privacy controls is unnecessary and risky. The default should be to minimize exposed state.
Suggested Fix
Remove isLogin from all external analytics/tracking requests. Move login state handling to first-party context (e.g., server-side checks or HttpOnly cookies) and send only non-identifying, consent-managed metrics. Implement a user consent gate for analytics; if no consent, disable analytics calls entirely.
Why Fix
Eliminates unnecessary exposure of authentication state to external services, reducing cross-site tracking risk and aligning with data minimization and privacy-by-default.
Route To
Privacy Engineer / Frontend & Backend Security
Page
Tester
Pete Β· Privacy Networking Analyzer
Technical Evidence
Console:
isLogin=0 observed in sp1.baidu.com/v.gif requestsNetwork:
GET https://sp1.baidu.com/-L-Xsjip0QIZ8tyhnq/v.gif?logactid=1234567890&showTab=10000&opType=showpv&mod=superman%3Alib&submod=index&superver=supernewplus&glogid=2151366034&type=2011&pid=315&isLogin=0&version=PCHome&terminal=PC&...&from_login=&from_reg=&query=&curcard=22
Session ID transmitted in URL query parameters (SID in API call)
CRIT P9
Prompt to Fix
Refactor authentication/session handling to stop transmitting session identifiers in URLs. Implement session management via Secure, HttpOnly, SameSite cookies and/or Authorization header tokens. Remove all sensitive or session-related data from query strings, and ensure server-side logs do not capture query parameters containing IDs. Add CSRF protection for state-changing requests and enforce strict logging redaction for URL parameters.
Why it's a bug
The SID is passed as a URL query parameter in a POST request to mbd.baidu.com. URLs and their query strings can be logged by servers, proxies, and browser history or referer headers, potentially exposing session identifiers and enabling session hijacking or replay attacks.
Why it might not be a bug
If the SID is strictly ephemeral and scoped to an isolated internal telemetry flow with rotation and strict access controls, risk is reduced. However, transmitting it in a URL remains a known insecure pattern that should be avoided.
Suggested Fix
Remove session identifiers from URL query strings. Use secure, HttpOnly cookies (with Secure and SameSite flags) or pass tokens in an Authorization header. If state-changing actions are required, implement CSRF protection and ensure tokens are not logged in any intermediary systems.
Why Fix
Eliminates exposure of session identifiers in logs/history and reduces risk of session hijacking and replay attacks.
Route To
Security Engineer
Page
Tester
Sharon Β· Security Networking Analyzer
Technical Evidence
Network:
POST https://mbd.baidu.com/ztbox?action=zpblog&appname=pcsearch&sid=63146_67721_67861_67885_67891_67942_67966_68042_67984_68002_68133_68142_68149_68152_68140_68189_68227_68263_68287_68288_68297_68309_68347_68369_68354_68433_68454_68441_68513_68529_68543_68551_68508_68517&v=2.0&data=%7B%22cateid%22%3A%2299%22%2C%22actiondata%22%3A%7B%22id%22%3A18463%2C%22type%22%3A%220%22%2C%22timestamp%22%3A1774518421029%2C%22content%22%3A%7B%22page%22%3A%22home%22%2C%22source%22%3A%22%22%2C%22from%22%3A%22search%22%2C%22type%22%3A%22display%22%2C%22value%22%3A%22%22%2C%22ext%22%3A%7B%22status%22%3A%22default%22%2C%22is_log%22%3A%220%22%2C%22have_hotsearch%22%3A%221%22%2C%22is_kuang_rec_disp%22%3A%221%22%2C%22search_kuang_status%22%3A%22default%22%2C%22aisou_btn%22%3A%220%22%2C%22kuang_rec_status%22%3A%221%22%7D%7D%7D%7D3
Insecure HTTP requests detected to baidu resources (http://www.baidu.com/more and /more/)
CRIT P9
Prompt to Fix
Action: Replace insecure HTTP calls to external resources with HTTPS. In the code path that loads assets from http://www.baidu.com/more and http://www.baidu.com/more/, change to https://www.baidu.com/more/ and ensure all references in HTML/JS/CSS use HTTPS. If hosting environment requires redirects, configure the server to 301/302-redirect all http:// requests to https:// and enable HSTS. Add or enforce a strict Content-Security-Policy and ensure assets are loaded over HTTPS only. Validate in the build pipeline that no http:// external URLs remain.
Why it's a bug
Several initial GET requests are sent over HTTP (non-HTTPS) to http://www.baidu.com/more and http://www.baidu.com/more/, which can be observed as insecure network transmissions. Even though some redirects to HTTPS are later observed, the initial exposure can be intercepted or tampered with in transit. This constitutes insecure transmission and could enable man-in-the-middle or content tampering for those requests. Mixed-content risk can also degrade user trust.
Why it might not be a bug
If these HTTP requests immediately redirect to HTTPS with secure resources and no sensitive data is ever transmitted via HTTP, the risk is mitigated. However initial HTTP requests are still a vulnerability and should be avoided; thus not a strong justification for leaving them as is.
Suggested Fix
Update all external resource URLs to use HTTPS (https://www.baidu.com/...), enforce HTTPS by default in the codebase, and ensure redirects from HTTP to HTTPS are properly implemented server-side with 301/302. Consider enabling HSTS and auditing assets for mixed-content. Remove or replace any http-only endpoints in the production code paths.
Why Fix
Using HTTPS by default protects against eavesdropping, tampering, and cookie/session hijacking. It also reduces mixed-content risks and preserves user trust and data integrity.
Route To
Platform Engineer / Frontend Security Engineer
Page
Tester
Sharon Β· Security Networking Analyzer
Technical Evidence
Network:
GET http://www.baidu.com/more - Status: 307; GET http://www.baidu.com/more/ - Status: 307