fix(cloud-tests): improve error messages and user feedback

[Alex-Alaniz]

• Extract clean messages from GCP/Azure error responses
• Add info banner explaining propagation delays (12-24h) for empty results
• Auto-dismiss error banners after 30 seconds

Fixes JSON blob display in GCP errors, adds context for empty scan results, and prevents error banner clutter.

What does this PR do?

• Fixes #XXXX (GitHub issue number)
• Fixes COMP-XXXX (Linear issue number - should be visible at the bottom of the GitHub issue description)

Visual Demo (For contributors especially)

A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).

Video Demo (if applicable):

• Show screen recordings of the issue or feature.
• Demonstrate how to reproduce the issue, the behavior before and after the change.

Image Demo (if applicable):

• Add side-by-side screenshots of the original and updated change.
• Highlight any significant change(s).

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
app	Ready	Preview	Comment	Oct 30, 2025 3:15pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal	Skipped			Oct 30, 2025 3:15pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

No OSV CVEs found in scanned packages; ResultsView.tsx exposes scanAccessToken to the browser and renders raw/unvalidated provider errors and findings.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 1 file(s) with issues

🔴 apps/app/src/app/(app)/[orgId]/cloud-tests/components/ResultsView.tsx (HIGH Risk)

#	Issue	Risk Level
1	scanAccessToken exposed to browser via props/useRealtimeRun	HIGH
2	Raw provider error messages rendered to UI (sensitive info leak)	HIGH
3	Unvalidated findings data rendered in client (potential injection or info leak)	HIGH

Recommendations:

1. Do not pass long-lived or privileged scan access tokens to the browser. Move scanning orchestration and provider access to a trusted server-side component or API. If client-side realtime functionality is required, use short-lived, narrowly-scoped, ephemeral tokens minted by the server.
2. Avoid rendering raw provider error payloads to users. Replace detailed provider errors with a generic user-facing message (e.g., "An error occurred during the scan. Please try again.") and log the full error server-side for debugging. If parsing is required, extract only non-sensitive fields and redact any credentials, IDs, stack traces, or request/response bodies.
3. Validate and normalize all findings on the server before returning them to the client. Only return minimal, sanitized fields necessary for the UI. On the client, escape/encode any user- or provider-controlled strings before inserting into the DOM. Avoid dangerouslySetInnerHTML; if rich content is required, sanitize it using a vetted library (e.g., DOMPurify) on the server or client prior to rendering.
4. Adopt least-privilege access for scanning tokens (minimal scopes) and make them short-lived. Implement server-side auditing and monitoring of token use.
5. Centralize error handling: detailed diagnostics and stack traces should remain server-side. Use correlation IDs to help users report issues without exposing internals.
6. Add Content Security Policy (CSP) and other frontend hardening to mitigate impact of potential XSS, and ensure findings data is treated as untrusted input.

---

💡 Recommendations

View 3 recommendation(s)

1. Remove scanAccessToken from client props/useRealtimeRun. Keep any long‑lived or privileged tokens out of ResultsView.tsx and perform scanning/authorization on a trusted server endpoint (or mint narrowly scoped, short‑lived tokens server‑side).
2. Stop rendering raw provider error payloads from ResultsView.tsx. Replace with a generic user message and map/log detailed provider errors server‑side; ensure any displayed error fields are explicitly whitelisted and redacted of IDs, stack traces, and request/response bodies.
3. Validate and sanitize all findings before inserting into the DOM in ResultsView.tsx. Escape or encode provider/user‑controlled strings, avoid dangerouslySetInnerHTML, and only render minimal, vetted fields. If rich HTML must be shown, sanitize it with a vetted sanitizer prior to render.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Oct 30, 2025

[claudfuen]

🎉 This PR is included in version 1.56.5 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀