B-80%
Quality Score
7
Pages
133
Issues
8.2
Avg Confidence
8.1
Avg Priority
72 Critical42 High19 Medium
>_ Testers.AI
AI Analysis
Replit was tested and 133 issues were detected across the site. The most critical finding was: Sensitive Sentry key exposure in CSP error log URL. Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (4/10).
Qualitative Quality
Replit
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
replit.com
replit.com
replit.com
replit.com
replit.com
replit.com
Detected Issues · 133 total
1
Sensitive Sentry key exposure in CSP error log URL
CRIT P9
Prompt to Fix
Update the CSP handling to remove any secret keys from sources and log messages. Do not reference URLs or query parameters that contain credentials in CSP errors. Move Sentry configuration to a secure backend, and ensure CSP logs are sanitized to redact secrets before being emitted.
Why it's a bug
The console logs contain a CSP error line that references a URL with a sentry_key query parameter (sentry_key=74a33d973a69190986eba8f4bca540d2). This exposes a credential-style value in client-side logs and CSP error messages, which could be captured by logs, error reports, or browser history and used for targeted attacks or abuse.
Why it might not be a bug
If the sentry_key is a public DSN or non-secret identifier, exposure may be less critical. However, best practice is to avoid logging any secret or credential-like values in client-side logs, regardless of its perceived sensitivity.
Suggested Fix
Remove or redact the sentry_key from CSP error logs and from any CSP source strings. Do not construct CSP sources with secret keys. Move Sentry configuration server-side and use a public DSN only where appropriate. Sanitize all console/error logs to strip query parameters containing secrets.
Why Fix
Prevents credential leakage through client logs and CSP diagnostics, reducing risk of session hijack or misuse of secret keys in error reporting channels.
Route To
Frontend Security Engineer
Page
Tester
Sharon · Security Console Log Analyzer
Technical Evidence
Console:
[ERROR] The source list for the Content Security Policy directive 'default-src' contains an invalid source: ''unsafe-dynamic''. It will be ignored.Network:
/api/4509640700461056/security/?sentry_key=74a33d973a69190986eba8f4bca540d22
Unconsented third-party telemetry to Sentry (privacy/tracking risk)
CRIT P9
Prompt to Fix
Identify the Sentry telemetry POST to https://o1151714.ingest.us.sentry.io/api/4509640700461056/envelope/?sentry_version=7&sentry_key=74a33d973a69190986eba8f4bca540d2&sentry_client=sentry.javascript.nextjs%2F9.47.1 observed in production. Implement opt-in consent gating for telemetry, scrub PII from payloads (remove user identifiers, IPs, emails, etc.), and configure Sentry with beforeSend to redact sensitive data. Set sendDefaultPii=false and consider a privacy-friendly alternative (aggregated metrics) if consent is not given. Update UI/privacy policy to reflect data collection and obtain user consent where required.
Why it's a bug
A POST request to a third-party telemetry service (o1151714.ingest.us.sentry.io) is observed without any visible user consent indicator in the traffic. This constitutes potential user tracking and data sharing with a third party. The payload may include diagnostic data that could contain PII, making it a privacy violation risk and potential regulatory non-compliance.
Why it might not be a bug
Telemetry is commonly used for crash/reporting; if a robust opt-in/consent flow and privacy policy exist, this could be acceptable. However, no evidence of explicit user consent is shown in the captured data, and default opt-in without consent is a privacy risk.
Suggested Fix
Move Sentry telemetry behind an explicit consent toggle, or completely disable non-essential telemetry in production. Implement data minimization: scrub PII from events, set beforeSend to redact user data, IP addresses, and other identifiers. Configure Sentry with sendDefaultPii=false, and consider aggregating/anonymizing data. Gate telemetry behind a feature flag or consent management UI and document in the privacy policy.
Why Fix
Reducing third-party data sharing and eliminating unconsented tracking preserves user privacy, aligns with data minimization principles, and helps meet regulatory requirements (e.g., GDPR/CCPA) while preserving user trust.
Route To
Privacy Engineer / Frontend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
POST https://o1151714.ingest.us.sentry.io/api/4509640700461056/envelope/?sentry_version=7&sentry_key=74a33d973a69190986eba8f4bca540d2&sentry_client=sentry.javascript.nextjs%2F9.47.1 - Status: N/ANetwork:
POST https://o1151714.ingest.us.sentry.io/api/4509640700461056/envelope/?sentry_version=7&sentry_key=74a33d973a69190986eba8f4bca540d2&sentry_client=sentry.javascript.nextjs%2F9.47.13
Exposure of Sentry DSN key in URL in console logs
CRIT P9
Prompt to Fix
Audit client-side code paths that construct URLs or CSP sources to ensure no query parameters containing credentials or secrets are logged or exposed. Remove '/api/.../security/?sentry_key=...' from CSP sources and any console logs. If Sentry DSN is required, configure it server-side or via environment variables and reference it without logging. Implement a log sanitizer that redacts query parameters such as sentry_key, token, dsn, api_key from all logs. Validate all network calls and CSP configurations to ensure secrets are never included in logs or client-visible configurations. After changes, verify there are no occurrences of 'sentry_key' in the console or in CSP error messages.
Why it's a bug
The console log reveals a URL containing the query parameter 'sentry_key' with a long key value. This appears to be a Sentry DSN/public key used to report errors to the Sentry service. Exposing this in client-side logs can leak secrets, enable misuse of the error-reporting channel, and reveal internal service identifiers. Even if the DSN/public component is intended for client use, logging it increases the attack surface and violates best practices for secret handling.
Why it might not be a bug
In some deployments, the Sentry DSN/public key is intended for client usage and may be public. However, logging any credential or key is still a security/privacy risk and should be avoided; redacting such values is best practice even if the key itself is not strictly secret.
Suggested Fix
Do not log or expose any URLs that contain credentials or secret-like query parameters (e.g., sentry_key). Remove the sentry_key parameter from CSP sources and from any client-side logs. Sanitize logs by redacting sensitive query parameters and, if using Sentry, move DSN configuration to a secure, non-logged location. Update CSP generation to use only trusted hosts without secrets in the path or query string.
Why Fix
Preventing exposure of Sentry keys and related identifiers protects against credential leakage, reduces risk of abuse of the error-reporting channel, and upholds privacy-by-design principles.
Route To
Frontend Security Engineer
Page
Tester
Pete · Privacy Console Log Analyzer
Technical Evidence
Console:
[ERROR] The source list for Content Security Policy directive 'default-src' contains a source with an invalid path: '/api/4509640700461056/security/?sentry_key=74a33d973a69190986eba8f4bca540d2'. The query component, including the '?', will be ignored.Network:
/api/4509640700461056/security/?sentry_key=74a33d973a69190986eba8f4bca540d2