Slerf.Tools
App Quality Report
Powered by Testers.AI
B+88%
Quality Score
6
Pages
71
Issues
8.1
Avg Confidence
7.7
Avg Priority
29 Critical25 High16 Medium1 Low
Testers.AI
>_ Testers.AI AI Analysis

Slerf.Tools was tested and 71 issues were detected across the site. The most critical finding was: Unconsented third-party tracking beacon (Cloudflare Insights) loaded on page. Issues span Security, A11y, Performance, Other categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).

Qualitative Quality
Slerf.Tools
Category Avg
Best in Category
Issue Count by Type
UX
14
Content
12
Security
7
A11y
2
Pages Tested · 6 screenshots
Detected Issues · 71 total
1
Unconsented third-party tracking beacon (Cloudflare Insights) loaded on page
CRIT P9
Conf 9/10 Other
Prompt to Fix
Do not load Cloudflare beacon.min.js until the user provides explicit consent. Implement a privacy-consent toggle in the UI; conditionally load the script only after consent; ensure no cookies or IP-affecting data are shared prior to consent; add a privacy notice explaining what data is collected and why; provide a code snippet to load the beacon only on consent (e.g., wrap the script injection in a consent-check function) and a fallback if consent is denied.
Why it's a bug
A beacon script from Cloudflare Insights is loaded (beacon.min.js) and appears to transmit telemetry to a third-party analytics service. There is no evidence of explicit user consent gating or privacy notice in the provided activity. This enables potential user tracking and IP address exposure across sites.
Why it might not be a bug
Analytics beacons are common for performance/monitoring, typically allowed with a privacy notice and user consent; however, no consent mechanism is shown in the log.
Suggested Fix
Gate the Cloudflare beacon behind explicit user consent and a privacy notice. Add an opt-out option, load the beacon only after consent, and minimize data collection. Consider using privacy-preserving analytics or deferring non-essential telemetry.
Why Fix
Reduces cross-site tracking, improves user trust, and aligns with privacy-by-design and data-minimization principles.
Route To
Privacy Engineer / Frontend Security
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console: GET https://static.cloudflareinsights.com/beacon.min.js/... - Status: 200
Network: GET https://static.cloudflareinsights.com/beacon.min.js/v8c78df7c7c0f484497ecbca7046644da1771523124516 - Status: 200
2
AI endpoints invoked on page load (privacy/perf risk)
CRIT P9
Conf 9/10 PerformanceOther
Prompt to Fix
Actionable: Remove or lazy-load all AI/LLM endpoint calls during initial render. Wrap them in a user-initiated action (button click) or in a component that loads after user consent. Add a privacy notice and log when LLM calls occur, and implement retry/backoff with exponential delays.
Why it's a bug
Console shows frequent AI/LLM endpoint detections on page load, suggesting embedding/LLM calls are triggered automatically instead of on user action. This can degrade performance, increase data exposure without consent, and contradict best practices for GenAI integrations.
Why it might not be a bug
If the app relies on LLM-based content during initial render, it should be clearly consented and gated behind user action; otherwise this is a security/privacy risk and user trust issue.
Suggested Fix
Move all AI/LLM calls behind explicit user action; add a consent banner and data use disclosure; implement lazy-loading with dynamic import; batch requests and add exponential backoff; remove preloads triggered by LLM endpoints.
Why Fix
Reduces latency, protects user privacy, and aligns with performance budgets; improves user trust.
Route To
Frontend Engineer / Privacy/Security Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console: [WARN] The resource https://fonts.reown.com/KHTeka-Medium.woff2 was preloaded using link preload but not used within a few seconds from the window's load event.
Network: GET https://rpc-bridge.slerf.tools/bsc - Status: 204
3
Public RPC bridge endpoint allows unauthenticated POST to broadcast Ethereum transactions
CRIT P9
Conf 9/10 SecurityOther
Prompt to Fix
Update the RPC bridge endpoint to require and validate an Authorization header (e.g., Bearer JWT) for POST /eth requests. Add server-side verification of the token, tie requests to the user session, implement rate limiting (per-IP and per-user), and log all attempts. If using cookies for auth, implement CSRF protection and set Secure, HttpOnly, and SameSite flags. After changes, run a security review and load test to ensure no legitimate users are blocked and abuse is mitigated.
Why it's a bug
The network activity shows a POST to https://rpc-bridge.slerf.tools/eth without any visible authentication in the logs. If this endpoint accepts transaction-broadcast requests without proper authentication or authorization checks, it could be abused by a malicious actor to submit transactions or drain user resources. This represents a high-risk surface for asset loss and abuse.
Why it might not be a bug
The absence of visible auth in logs does not prove misconfiguration; the endpoint could be protected by headers or server-side session management not reflected in this trace. A legitimate gateway could use tokens or signed requests. However, given the critical nature of Ethereum transaction submission, this requires explicit confirmation and hardening.
Suggested Fix
Implement strong authentication for POST /eth (e.g., require a valid JWT or API key in Authorization header), enforce per-user authorization checks, apply strict input validation, and enable rate limiting. Consider requiring signed requests or mTLS for server-to-server calls. Implement CSRF protection if cookies are used for auth and audit all access with strict logging.
Why Fix
Prevent unauthorized or automated misuse of the RPC gateway, which could lead to unauthorized transactions, fund loss, or platform abuse. Strengthening authentication and rate limiting reduces abuse risk and protects user assets.
Route To
API Security Engineer
Page
Tester
Sharon · Security Networking Analyzer
Technical Evidence
Network: POST https://rpc-bridge.slerf.tools/eth - Status: N/A
+30
30 more issues detected  View all →
Third-Party Wallet Identifiers Shared with web3modal.org Wit...
AI/LLM endpoint detected in page assets (potential data leak...
Real User Monitoring (RUM) data collection via Cloudflare cd...
and 27 more...
Unlock All 71 Issues
You're viewing the top 3 issues for Slerf.Tools.
Sign up at Testers.AI to access the full report with all 71 detected issues, detailed fixes, and continuous monitoring.
Sign Up at Testers.AI or let us run the tests for you