[comp] Production Deploy

[github-actions]

This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.

[comp-ai-code-review]

🔒 Comp AI - Security Review

🟡 Risk Level: MEDIUM

Hardcoded client-side token (LOGO_TOKEN) and several unvalidated route/URL params (orgId, setupId, inviteCode) leading to DB-query injection and stored XSS risks in pages/components.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 7 file(s) with issues

🟡 apps/app/src/app/(app)/[orgId]/integrations/components/IntegrationsGrid.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Hardcoded client-side token LOGO_TOKEN exposing secret	MEDIUM

Recommendations:

1. Remove the hardcoded token from client-side code and store it in a secure server-side environment variable.
2. Serve the image (or proxy the request) from a server-side endpoint that injects the token, so the token never appears in client-side source or network requests visible to users.
3. If the token must be public, confirm it is a true public/publishable token with minimal scope and no write/privileged permissions; document that explicitly and rotate it regularly.
4. Use short-lived tokens or issue tokens scoped to specific domains/IPs where possible.
5. Whitelist and validate integration.domain values server-side before embedding them into external URLs to prevent misuse.
6. Rotate the current token immediately if it was intended to be secret or has broader permissions than necessary.

🟡 apps/app/src/app/(app)/onboarding/[orgId]/layout.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	No validation of params (orgId) format or type	MEDIUM
2	Organization object passed to client components may expose sensitive data	MEDIUM

Recommendations:

1. Validate and enforce orgId format (e.g., require UUID v4) at the route boundary before using it. Reject or 400 for invalid values.
2. Perform explicit type-checking and normalization of params (string -> expected type) rather than trusting route params.
3. Limit the fields returned from the database (use a select/projection) so only minimal, non-sensitive organization fields are sent to components.
4. If MinimalHeader or other components are client-side, ensure only sanitized/whitelisted props are passed (do not pass entire ORM entity).
5. Add explicit authorization checks and clearer error handling/logging for failed membership checks (avoid generic notFound for all failures if you need auditing).
6. Log and monitor suspicious access patterns to organization endpoints (rate-limit/alert on repeated invalid orgId attempts).

🟡 apps/app/src/app/(app)/onboarding/[orgId]/page.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated orgId used directly in DB query	MEDIUM
2	Host header controls isLocal logic and can be spoofed	MEDIUM
3	Unvalidated organization.context answers passed to UI (XSS risk)	MEDIUM

Recommendations:

1. Validate and constrain orgId (UUID/number) before DB queries
2. Do not rely on Host header for prod/dev logic; use env flags
3. Remove or gate local prefills by server env, not client headers
4. Sanitize/escape context answers before rendering in UI
5. Confirm ORM parameterization; enforce input schemas

🟡 apps/app/src/app/(app)/onboarding/components/PostPaymentOnboarding.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Client-side-only validation; inputs can be bypassed	MEDIUM

Recommendations:

1. Enforce the same validation rules on the server-side for any data submitted from this onboarding form. Never trust client-side checks alone.
2. On the API/handler that receives onboarding answers, validate types, required fields, allowed lengths, and allowed values (e.g., ensure frameworkIds is an array of known IDs).
3. Apply authorization checks on the server to ensure the submitting user is allowed to modify the targeted organization.
4. Rate-limit and CSRF-protect the endpoint that handles onboarding submissions to reduce abuse.
5. Keep comprehensive logging and monitoring for unexpected input/behavior from onboarding endpoints so bypass attempts can be detected.

🟡 apps/app/src/app/(app)/setup/[setupId]/page.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unsanitized setupId passed to getSetupSession (DB injection risk)	MEDIUM
2	setupSession.formData passed to UI without validation (stored XSS risk)	MEDIUM
3	inviteCode from URL used directly in redirect path (path/injection risk)	MEDIUM
4	No explicit server-side validation of URL params (setupId/inviteCode)	MEDIUM

Recommendations:

1. Validate and constrain setupId (e.g. UUID regex) before use
2. Ensure getSetupSession uses parameterized/ORM queries
3. Whitelist/validate inviteCode characters and length
4. Sanitize/escape setupSession.formData before rendering
5. Add centralized server-side validation for all URL params

🟢 apps/app/src/app/(app)/setup/components/FrameworkSelection.tsx (LOW Risk)

#	Issue	Risk Level
1	Unvalidated JSON from /api/frameworks used directly	LOW

Recommendations:

1. Validate the response schema before calling setFrameworks. Use a runtime validation library (e.g., zod, io-ts) or explicit checks: ensure data.frameworks is an array and each item has the expected keys/types (id:string, name:string, description?:string, version?:string, visible?:boolean).
2. Map/whitelist fields from the response instead of assigning the raw object: setFrameworks(data.frameworks.map(f => ({ id: String(f.id), name: String(f.name), description: String(f.description || ''), version: String(f.version || ''), visible: Boolean(f.visible) }))). This prevents unexpected shapes/prototype pollution.
3. Sanitize or normalize any fields that may later be used in contexts where HTML is injected. Although current components render text (React escapes by default) and do not use dangerouslySetInnerHTML, future changes could introduce sinks—sanitize before storing/using.
4. Handle non-JSON and malformed responses robustly: check Content-Type (application/json) when appropriate and guard against response.json() throwing by keeping the try/catch (already present) and validating the parsed value before use.
5. Abort the fetch on unmount using AbortController to avoid setting state on unmounted components and to free network resources when the user navigates away.
6. If the frameworks list is sensitive or should be restricted, require authentication/authorization on the API and surface only the minimal required data to the client.

🟡 apps/app/src/app/(app)/setup/layout.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Spoofable x-intent header allows routing/auth bypass; no validation	MEDIUM
2	Session derived directly from request headers; header spoofing may affect auth	MEDIUM
3	Users with an org can re-run setup by setting x-intent to create-additional	MEDIUM

Recommendations:

1. Do not rely on a client-supplied 'x-intent' header for access or routing decisions. Treat it as untrusted input and validate/whitelist permitted values server-side before using it.
2. Enforce server-side authorization checks (ownership/permission checks) before allowing access to setup flows or creation of additional organizations. Ensure that only users with explicit permission can create additional orgs.
3. Derive session information only from trusted authentication tokens/cookies that your auth provider expects. When calling auth.api.getSession, pass only the canonical request cookies or server-validated tokens instead of blindly forwarding all incoming headers.
4. Avoid using a simple header flag to bypass redirects. If an explicit action is required (e.g., create an additional org), require a POST request with CSRF protection and an authenticated/authorized session check rather than a custom header.
5. Log and alert on unusual use of 'x-intent' (or other custom intent headers) and rate-limit endpoints that initiate setup or org creation to detect misuse.
6. Add explicit server-side checks for onboardingCompleted and membership before allowing access to onboarding/setup routes; do not rely on the absence/presence of a header to decide whether to run setup.

---

💡 Recommendations

View 3 recommendation(s)

1. Remove the hardcoded LOGO_TOKEN from apps/app/src/app/(app)/[orgId]/integrations/components/IntegrationsGrid.tsx. Instead, implement a server-side endpoint (e.g. /api/proxy-logo?domain=...) that reads the token from server-only config and returns or proxies the image; update the component to call that endpoint (encode integration.domain) so the token never appears in client source or outgoing client requests.
2. Validate and coerce all route/URL params before using them in DB queries: in onboarding/[orgId]/page.tsx, onboarding/[orgId]/layout.tsx, setup/[setupId]/page.tsx, and related handlers enforce a schema (e.g., UUID regex or Number.parseInt) or use a runtime validator (zod) and return 4xx for invalid values. Also ensure ORM calls use parameterized queries/ORM methods with the validated values (do not interpolate raw params into query strings).
3. Do not pass raw DB entities or free-form formData/context objects directly to client components. Whitelist and project only the minimal fields needed server-side, and sanitize/escape string values before rendering to prevent stored XSS (or use an HTML sanitizer only if HTML must be allowed). Avoid rendering untrusted HTML (no dangerouslySetInnerHTML) unless explicitly validated and sanitized.

---

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

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app (staging)	Ready	Preview	Comment	Oct 23, 2025 4:18pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal (staging)	Skipped			Oct 23, 2025 4:18pm

[claudfuen]

🎉 This PR is included in version 1.56.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀