B85%
Quality Score
4
Pages
50
Issues
7.8
Avg Confidence
7.8
Avg Priority
20 Critical19 High11 Medium
>_ Testers.AI
AI Analysis
Rezidency Ai was tested and 50 issues were detected across the site. The most critical finding was: Sentry DSN key exposed in client-side network request URL. Issues span Security, Legal, A11y, Performance categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).
Qualitative Quality
Rezidency Ai
Category Avg
Best in Category
Pages Tested · 4 screenshots
Homepage
lovable.dev.products.rezidency
lovable.dev.products.rezidency
lovable.dev.products.rezidency
Detected Issues · 50 total
1
Sentry DSN key exposed in client-side network request URL
CRIT P9
Prompt to Fix
Action: In the client app, locate the Sentry initialization code. Ensure the Sentry DSN used on the client is a public DSN and that there are no secret tokens in the URL query parameters. If a secret DSN was previously used on the frontend, move error reporting to a backend service that securely injects the DSN, or switch to using a fully public DSN with proper data scrubbing. Update the instrumentation to scrub PII from error payloads. Validate the network requests to Sentry so that the URL contains only the public DSN components and no sensitive tokens.
Why it's a bug
The client makes a POST request to a Sentry ingestion endpoint with the sentry_key parameter in the URL: https://o4506071217143808.ingest.us.sentry.io/api/4506071220944896/envelope/?sentry_version=7&sentry_key=58ff8fddcbe1303f19bc19fbfed46f0f&sentry_client=sentry.javascript.nextjs%2F10.28.0. Exposing a token-like parameter in the URL can be captured in browser history, server logs, referer headers, and analytics tools, increasing the risk of credential leakage and potential misuse if the key is abused. While Sentry public DSN keys are intended to be public, placing them in the URL adds unnecessary exposure.
Why it might not be a bug
Sentry public DSN keys are designed to be public and are commonly included in client-side configurations. The key in the URL is standard for how Sentry accepts events from clients. Exposure in the URL, while not ideal, does not typically allow secret access or write permissions beyond what the public DSN permits. However, it does increase surface area for leakage through logs and history.
Suggested Fix
Verify that the DSN used in the client is the public DSN and ensure no secret tokens are embedded in the URL. If a secret DSN is inadvertently used on the client, refactor to route error reporting through a backend API that injects the DSN securely. Consider rotating the DSN and/or switching to a fully public DSN serialized via environment configuration, and scrub any sensitive data from error payloads before sending.
Why Fix
Minimizing token exposure in URLs reduces the risk that tokens are captured in logs, browser history, or analytics and misused by attackers to post spoofed events or gain insight into project configuration.
Route To
Frontend Security Engineer
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Network:
POST https://o4506071217143808.ingest.us.sentry.io/api/4506071220944896/envelope/?sentry_version=7&sentry_key=58ff8fddcbe1303f19bc19fbfed46f0f&sentry_client=sentry.javascript.nextjs%2F10.28.02
Unconsented third-party telemetry to Sentry (tracking / data sharing)
CRIT P9
Prompt to Fix
In your Next.js app, implement consent-gated Sentry telemetry. Before initializing Sentry or sending events, check a user consent flag for analytics/telemetry. If consent not granted, skip Sentry.init and do not call Sentry.capture*. Update Sentry config to minimize data: set sendDefaultPII to false, implement a beforeSend that strips potential PII (e.g., event.user.email, event.user.name, IP address, and any session identifiers), and remove or anonymize user-identifying tags from events. If possible, route error reporting to a server-side endpoint that does not reveal user data. Add a privacy policy link and a user-facing consent banner; persist choice across sessions. Replace the DSN with a non-identifying telemetry option if available and ensure only non-identifying data is transmitted.
Why it's a bug
The client makes a POST to a Sentry ingest endpoint (third-party) which transmits telemetry data. This constitutes data sharing with a third-party analytics/monitoring service. There is no visible evidence of user consent gating for telemetry in the provided network activity, and the request includes a Sentry envelope call that could carry error data, environment info, and potentially PII. This exposes user data to a third party and risks regulatory compliance and user trust.
Why it might not be a bug
Telemetry to Sentry is a common practice for error monitoring; if the consent mechanism is implemented and PII is sanitized, this may be acceptable. Additionally, if the Sentry DSN is properly scoped to non-identifying telemetry and consent is obtained via a policy, it might not be a privacy violation.
Suggested Fix
Implement consent-gated, privacy-preserving telemetry: 1) Gate Sentry initialization and event sending behind explicit user consent for analytics/telemetry. 2) Do not send PII: set sendDefaultPII to false and scrub any user-identifying fields in beforeSend. 3) Remove or obfuscate user identifiers from event contexts. 4) Consider server-side error logging to minimize client-side data exposure. 5) Ensure a visible privacy-consent toggle and policy link; respect user preferences across sessions. 6) If possible, move non-critical telemetry to opt-in or disable in production.
Why Fix
Fixing this reduces exposure of user data to a third party, improves compliance with data protection laws, and increases user trust and product quality.
Route To
Frontend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
No explicit console messages related to this privacy issue were captured in the provided snippet.Network:
POST https://o4506071217143808.ingest.us.sentry.io/api/4506071220944896/envelope/?sentry_version=7&sentry_key=58ff8fddcbe1303f19bc19fbfed46f0f&sentry_client=sentry.javascript.nextjs%2F10.28.03
On-page AI/LLM endpoints detected on page load
CRIT P9
Prompt to Fix
Review all page-load network requests for potential AI/LLM endpoints. Remove or defer any non-critical AI calls until explicit user action is taken. Add consent prompts or toggles for AI features, and implement guarded retries with backoff for any required AI interactions.
Why it's a bug
Network activity logs show 'AI/LLM ENDPOINT DETECTED' for resources loaded during initial page load (including signup and font assets). This implies AI/LLM endpoints may be contacted without user interaction, posing privacy, performance, and potential governance concerns.
Why it might not be a bug
If these detections are false positives from a monitoring tool, they could still indicate misclassification. However, visible evidence suggests potential on-load AI usage that should be scrutinized.
Suggested Fix
Remove or lazy-load any AI/LLM endpoint calls that are not strictly required for initial render. Gate AI/LLM interactions behind explicit user action or consent, and implement proper rate limits/backoff. Ensure telemetry/api calls are clearly separated from user data paths and documented.
Why Fix
Improves user privacy, reduces unnecessary network traffic, and aligns with best practices for AI integrations by avoiding silent on-load calls.
Route To
Frontend Engineer / Privacy & Security Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
[DEBUG] JSHandle@errorNetwork:
GET https://lovable.dev/signup?redirect=%2Fproducts%2Frezidency-ai - Status: 200