C+79%
Quality Score
7
Pages
161
Issues
8.1
Avg Confidence
8.0
Avg Priority
63 Critical80 High16 Medium2 Low
>_ Testers.AI
AI Analysis
Cursor was tested and 161 issues were detected across the site. The most critical finding was: Unconsented third-party analytics loader request detected. Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (5/10).
Qualitative Quality
Cursor
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
cursor.com
cursor.com
cursor.com
cursor.com
cursor.com
cursor.com
Detected Issues · 161 total
1
Unconsented third-party analytics loader request detected
CRIT P9
Prompt to Fix
Actionable prompt for AI coding assistant: 1) Detect the analytics loader at 0ay7zb.cursor.com/analytics/loader-v1.js and the query parameter key. 2) Implement a consent gating mechanism: show a clear privacy banner with an opt-in for analytics; store user consent in a marker (e.g., localStorage) and require consent before loading any analytics script. 3) Remove or redact the 'key' parameter from the analytics loader URL unless it is strictly required and only sent after consent is granted. 4) Ensure the analytics payloads contain no PII, minimize data collection, and anonymize user identifiers. 5) Add CSP and SRI to restrict third-party script loading. 6) Provide a server-side toggle to disable analytics entirely for testers. 7) Document data types collected and retention policy in a privacy notice.
Why it's a bug
A tracking/analytics loader is being requested from a subdomain (0ay7zb.cursor.com) with a key parameter, suggesting user activity is being collected without explicit consent indicators or privacy disclosures. This can enable user tracking across sites and constitutes potential data collection without opt-in.
Why it might not be a bug
If the site relies on analytics with proper consent banners and clear disclosures, this may be legitimate. However, from the provided activity, there is no visible consent indication or minimization controls, so this is flagged as a privacy risk unless proven otherwise.
Suggested Fix
Require explicit user consent before loading analytics/tracking scripts; implement a consent banner and store consent state. Move analytics behind a feature flag or user opt-in. Ensure the loader does not transmit any potentially identifying data in URL parameters; minimize collected data, anonymize IDs, and respect Do Not Track. Consider using a privacy-friendly analytics solution or first-party analytics under strict privacy controls.
Why Fix
Fixing this reduces risk of non-compliant data collection, protects user privacy, builds trust, and aligns with data protection regulations by ensuring tracking occurs only with consent and with minimized data exposure.
Route To
Frontend Engineer / Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
⚠️ POTENTIAL ISSUE: Tracking request detectedNetwork:
GET https://0ay7zb.cursor.com/analytics/loader-v1.js?key=6f091e8fd6f3c36209a1e08f140c7a4b334baea548f4702052f0732f8d577990 - Status: N/A2
Exposed tracking identifiers in console logs (cid/auid/tid)
CRIT P9
Prompt to Fix
Implement log redaction for all analytics/tracking parameters prior to console output. Specifically mask or remove CID, AUID, TID, TIDS, GTM IDs, and any other query parameters that function as user/session identifiers in URLs printed to the console. Replace with placeholders or hashed values. Ensure production builds do not print full analytics URLs in logs. Add automated tests to verify that console logs do not leak tracking identifiers.
Why it's a bug
The console logs reveal persistent user/tracking identifiers (e.g., cid, gtm, aup, auid, tids, tid) embedded in analytics/advertising URLs. These identifiers can be used to correlate user activity across sites or sessions if logs are accessed by developers, QA, or leaked. Although not traditional PII like names or emails, these IDs function as cross-site tracking tokens and pose a privacy risk when exposed in logs.
Why it might not be a bug
In some setups, analytics IDs are intentionally present for debugging and may be considered non-sensitive. However, exposing them in console logs increases the attack surface for misuse and privacy violations, especially if logs are accessible in production or to third parties.
Suggested Fix
Redact or hash tracking identifiers in all console/log outputs. Implement a centralized log sanitizer that masks parameters such as cid, auid, tid, tids, gtm, and any other analytics tokens before printing. Disable verbose analytics logging in production or route such data to secure backends only. Review and remove unnecessary URLs from console logs.
Why Fix
Masking tracking identifiers reduces the risk of cross-site user profiling from exposed logs, aligns with privacy-by-design principles, and mitigates potential data leakage or misuse by internal teams or third parties.
Route To
Frontend Security Engineer / Privacy Engineer
Page
Tester
Pete · Privacy Console Log Analyzer
Technical Evidence
Console:
[ERROR] Connecting to 'https://stats.g.doubleclick.net/g/collect?v=2&tid=G-5H6JBHFD7Z&cid=767046130.1774469730>m=45je63o0v9238630528z89237776711za20gzb9237776711zd9237776711&aip=1&dma=0&gcd=13l3l3l3l1l1&npa=0&frm=0&tag_exp=103116026~103200004~115938465~115938469~116024733~117266401~117484252' violates the following CSP directive: "connect-src 'self' cursor.com *.cursor.com cursor.sh *.cursor.sh unifyintent.com *.unifyintent.com *.cloudfront.net pro.ip-api.com *.liadm.com *.usbrowserspeed.com alocdn.com 9xgnrndqve.execute-api.us-west-2.amazonaws.com api.ashbyhq.com jobs.ashbyhq.com api.conceptualhq.com ip.conceptualhq.com *.facebook.com facebook.com featureassets.org prodregistryv2.org youtube.com *.youtube.com js.zi-scripts.com ws.zoominfo.com *.zoominfo.com *.chilipiper.com www.googletagmanager.com *.google-analytics.com analytics.google.com *.analytics.google.com *.roadwayai.com *.mux.com stream.mux.com inferred.litix.io". The action has been blocked.Network:
https://stats.g.doubleclick.net/g/collect?v=2&tid=G-5H6JBHFD7Z&cid=767046130.1774469730>m=45je63o0v9238630528z89237776711za20gzb9237776711zd9237776711&aip=1&dma=0&gcd=13l3l3l3l1l1&npa=0&frm=0&tag_exp=103116026~103200004~115938465~115938469~116024733~117266401~1174842523
PII/Identifiers exposed in analytics URL (auid parameter) in console/network logs
CRIT P9
Prompt to Fix
Actionable prompt: Refactor analytics collection to avoid sending user identifiers in client-side URLs. Remove auid parameter entirely or replace with an anonymized/hashed token. Switch to server-side analytics where possible; use POST requests for data transmission; ensure all analytics endpoints do not reveal PII in query strings. Update front-end code and analytics library configuration, and add tests to verify that no PII (including user IDs) is present in URL query parameters or browser logs. Add a Content-Security-Policy rule to limit analytics endpoints and ensure sensitive data is never exposed in logs.
Why it's a bug
The auid parameter in the Google Analytics/Google Ads collect URL is a user identifier that can be used to correlate across sessions. It is exposed in a client-side URL and captured in console/network logs, which could end up in browser history, server logs, or analytics dashboards. This constitutes leakage of potentially sensitive user identifiers (PII) and tracking data.
Why it might not be a bug
Marketing analytics often includes identifiers for tracking; however, exposing user identifiers in client-side URLs and logs increases privacy risk. Even if not strictly secret, these IDs can be used to re-identify users when combined with other data. Best practice is to anonymize or remove such identifiers from client-side requests.
Suggested Fix
Remove the auid parameter from client-side analytics URLs or replace it with a non-identifying, hashed/opaque token. Send only non-identifying analytics data. Consider switching to server-side processing for analytics where feasible and use POST requests (not GET) to avoid putting identifiers in URLs. Implement privacy-preserving analytics and validate logs to ensure no PII is exposed.
Why Fix
Reducing exposure of user identifiers in URLs and logs mitigates PII leakage, lowers risk of correlation across sessions, and aligns with privacy best practices and regulations.
Route To
Frontend Security Engineer / Privacy Engineer
Page
Tester
Sharon · Security Console Log Analyzer
Technical Evidence
Console:
[ERROR] Loading the image 'https://www.google.com/ccm/collect?frm=0&en=page_view&dl=https%3A%2F%2Fcursor.com%2F&scrsrc=www.googletagmanager.com&rnd=1519986609.1774469740&dt=Cursor%3A%20The%20best%20way%20to%20code%20with%20AI&auid=746754114.1774469730&navt=n&npa=0>m=45be63o0v9231728922za200zd9231728922xec&gcd=13l3l3l3l1l1&dma=0&tag_exp=103116026~103200004~115616985~115938465~115938469~116024733~117384405~117484252&apve=1&apvf=f&apvc=1&tids=AW-17332771332&tid=AW-17332771332&tft=1774469740262&tfd=712' violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval' cursor.com *.cursor.com cursor.sh *.cursor.sh *.unifyintent.com *.cloudfront.net pro.ip-api.com *.liadm.com *.usbrowserspeed.com alocdn.com va.vercel-scripts.com vercel.live jobs.ashbyhq.com os.ryo.lu connect.facebook.net js.zi-scripts.com ws-assets.zoominfo.com *.chilipiper.com www.googletagmanager.com *.googletagmanager.com *.roadwayai.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. The action has been blocked.Network:
https://www.google.com/ccm/collect?frm=0&en=page_view&dl=https%3A%2F%2Fcursor.com%2F&scrsrc=www.googletagmanager.com&rnd=1519986609.1774469740&dt=Cursor%3A%20The%20best%20way%20to%20code%20with%20AI&auid=746754114.1774469730&navt=n&npa=0>m=45be63o0v9231728922za200zd9231728922xec&gcd=13l3l3l3l1l1&dma=0&tag_exp=103116026~103200004~115616985~115938465~115938469~116024733~117384405~117484252&apve=1&apvf=f&apvc=1&tids=AW-17332771332&tid=AW-17332771332&tft=1774469740262&tfd=712