[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.

[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 21, 2025 4:38pm

1 Skipped Deployment

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

💡 Enable Vercel Agent with $100 free credit for automated AI reviews

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

No OSV/CVE vulnerabilities or hardcoded credentials were reported in the scanned packages; no known CVEs found by the OSV scan.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 7 file(s) with issues

🔴 apps/api/src/framework-editor/task-template/task-template.controller.ts (HIGH Risk)

#	Issue	Risk Level
1	No per-resource authorization checks; ownership/role not enforced	HIGH
2	Responses include authenticated user id/email, exposing PII	HIGH
3	Organization header optional; tenant access isn't enforced	HIGH
4	Possible SQL/DB injection in service.updateById if raw queries used	HIGH

Recommendations:

1. Enforce per-resource authorization (owner/role/tenant checks)
2. Remove or mask user PII from responses
3. Require and validate X-Organization-Id and enforce tenant scope
4. Use parameterized queries/ORM and sanitize inputs before DB use
5. Add audit logging and rate limiting for sensitive endpoints

🔴 apps/api/src/framework-editor/task-template/task-template.service.ts (HIGH Risk)

#	Issue	Risk Level
1	Missing input validation for id and updateDto before DB queries	HIGH
2	No authorization/access control checks for find/update/delete operations	HIGH
3	Unvalidated updateDto used directly in DB update may change unexpected fields	HIGH
4	Verbose logging exposes template names and IDs	HIGH
5	Errors and thrown exceptions include raw IDs and DB errors, leaking info	HIGH

Recommendations:

1. Validate and sanitize inputs: enforce ID shape (e.g., UUID) and validate UpdateTaskTemplateDto using class-validator or a schema (DTO validation pipe). Reject or sanitize unexpected properties.
2. Apply authorization checks before performing DB operations: use NestJS Guards/Policies/ACL at controller or service layer to ensure the caller has permission to view/update/delete the resource.
3. Whitelist fields for updates: map UpdateTaskTemplateDto to an explicit data object for db.update (only include allowed fields). Do not pass raw DTO directly to the ORM.
4. Limit returned data: avoid returning full DB error objects or potentially sensitive fields in API responses; return minimal confirmation or IDs only when necessary.
5. Redact sensitive data in logs: avoid logging full template names and raw IDs in info/error logs. Use non-identifying references or hash/partial IDs if needed for debugging.
6. Sanitize error messages: do not propagate raw DB errors to clients. Catch and translate internal errors to generic client-facing messages while logging details securely at debug level.
7. Add input size/structure checks: enforce max lengths and allowed characters on string fields in the DTO to reduce injection/abuse risks.
8. Adopt least privilege on DB operations: where possible, use ORM-level select/project to limit fields returned and updated.

🔴 apps/app/src/actions/tasks/create-task-action.ts (HIGH Risk)

#	Issue	Risk Level
1	Unvalidated header used in revalidatePath (x-pathname/referer)	HIGH
2	Weak path normalization regex may be bypassed	HIGH
3	IDOR: assigneeId accepted without org-membership check	HIGH
4	IDOR: controlIds connected without ownership/org checks	HIGH
5	IDOR: taskTemplateId accepted without ownership/org checks	HIGH
6	Weak auth check: only user.id presence verified	HIGH
7	No max length limits on title/description (DoS/storage risk)	HIGH
8	Verbose console.error logging may leak sensitive data	HIGH

Recommendations:

1. Whitelist and strictly validate the path used with revalidatePath. Do NOT accept arbitrary header values. Derive revalidation targets from known internal routes or map a small set of allowed tokens to routes. Reject or normalize headers that do not match the allowed set.
2. Avoid relying on a simple regex for locale stripping. Parse the path and normalize only expected patterns (e.g., use a robust router/path parser or explicit mapping for locales). Validate final path is an internal path (starts with '/', has no protocol/host, no //, no ../).
3. Enforce ownership/organization membership checks before setting assigneeId. Verify the referenced assignee is a member of activeOrganizationId and the acting user has permission to assign tasks.
4. Before connecting controls (controlIds), verify each control belongs to activeOrganizationId and that the acting user has permission to link those controls. Reject or filter out unknown/foreign IDs.
5. Validate that taskTemplateId (if present) belongs to the activeOrganizationId and that the user has permission to use it.
6. Do not assume presence of user.id is sufficient for authorization. Ensure authActionClient (or upstream middleware) enforces authentication and authorization; additionally, perform explicit permission checks in this action (roles, scopes, org membership, ability to modify/create tasks).
7. Add max length constraints (and sensible sanitization) to title and description in the zod schema to prevent excessive storage/DoS: e.g., title: z.string().min(1).max(255), description: z.string().min(1).max(5000) (adjust to your requirements).
8. Avoid logging full error objects to console in production. Sanitize/redact error details or log only error IDs and non-sensitive messages. Consider structured logging with levels and sensitive-data redaction.
9. If revalidatePath must accept external input, enforce server-only authoritative mapping (e.g., accept a route key or known route name instead of a header path).
10. Add unit/integration tests that assert invalid or foreign IDs are rejected and that revalidation only runs for allowed routes.

🟡 apps/app/src/app/(app)/[orgId]/tasks/components/CreateTaskSheet.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Client-side validation only; server-side validation not shown	MEDIUM
2	Auto-filling form from task templates without sanitization	MEDIUM
3	Server error details displayed to users via toast	MEDIUM
4	URL query 'create-task' controls UI state and is tamperable	MEDIUM

Recommendations:

1. Enforce server-side validation and sanitization in the create task endpoint (the createTaskAction handler). Mirror zod schema checks on the server, enforce length limits, allowed enum values, and reject/normalize unexpected fields.
2. Sanitize and validate task template data before using it to autofill form fields. Even though React escapes content in JSX, ensure server-side stored templates are validated and stripped of any unexpected markup or scripts. Prefer storing only plain text for title/description or sanitize on ingestion.
3. Do not display raw server error details to users. Log full server errors on the server and return a safe, generic message to the client (e.g., 'Failed to create task'). Update onError to show only non-sensitive messages and surface an error code if helpful for support.
4. Do not rely on URL query parameters as a security boundary. Treat query-driven UI state (useQueryState('create-task')) as UI-only and ensure any sensitive operations require server-side authorization checks. Validate on the server that the authenticated user is allowed to create tasks for the target org and that supplied IDs (assigneeId, controlIds, taskTemplateId, etc.) belong to that org.
5. Apply output escaping and input length limits for all user-controlled fields (title, description, control names). Use a robust sanitizer for any HTML-allowed fields and enforce maximum lengths to reduce injection/DoS risk.
6. Instrument server-side logging and monitoring for malformed or suspicious requests (unexpected enum values, atypically large payloads) and rate-limit task creation APIs to reduce abuse.

🟡 apps/app/src/app/(app)/onboarding/hooks/usePostPaymentOnboarding.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Sensitive PII (shipping, phone) persisted in localStorage	MEDIUM
2	Only current step schema validated; full payload may be unvalidated on submit	MEDIUM
3	User-provided answers sent to analytics (trackEvent) may leak PII or org data	MEDIUM
4	Storage keys built from organizationId can enable data leakage or tampering	MEDIUM
5	Client trusts savedAnswers when composing final payload without full validation	MEDIUM

Recommendations:

1. Do not store sensitive PII (full name, postal address, phone numbers) in localStorage. Use server-side session storage or ephemeral in-memory state for PII, or encrypt data before writing to browser storage with keys scoped to the user and origin (and store encryption keys server-side).
2. Perform full validation and sanitization of the entire onboarding payload on the server side (completeOnboarding action). Treat client-side validation as UX-only and never as authoritative. Use the existing zod companyDetailsSchema (or server-side equivalent) to validate all fields before persisting or acting on them.
3. Remove or redact any PII before sending analytics events. For analytics, send only non-identifying aggregate values or deterministic hashed identifiers (salted hash) that cannot be reversed to recover PII. Audit all trackEvent/trackOnboardingEvent calls to ensure they don't include address/phone/full name/org secrets.
4. Avoid relying solely on predictable storage keys to isolate data. Namespace keys with a server-provided per-user or per-session token (not a public organizationId) or tie storage to authenticated user/session state. Consider scoping sensitive data to server-side storage tied to the authenticated session.
5. Treat savedAnswers from localStorage as untrusted input. Re-validate/normalize any values read from storage before using them to construct final requests. Implement strict server-side authorization checks so a user cannot submit or finalize onboarding for another organization just by modifying localStorage.
6. Limit the lifetime and scope of persisted onboarding data: clear or expire partial answers frequently, and clear PII immediately after use. Consider using secure cookies or server-side ephemeral storage for any data that must survive navigation.
7. Add telemetry safeguards: maintain a denylist of fields that must never be sent to analytics, and add automated checks or unit tests ensuring PII fields are never included in tracking payloads.

🟡 apps/app/src/app/(app)/setup/actions/create-organization-minimal.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated header-derived path used in revalidatePath	MEDIUM
2	Arbitrary revalidation may cause DoS or cache tampering	MEDIUM
3	Framework IDs not whitelisted or validated for allowed values	MEDIUM
4	Stored inputs (website/frameworks) saved without output encoding	MEDIUM
5	Internal error.message returned to client (info disclosure)	MEDIUM

Recommendations:

1. Validate and normalize the header-derived path before calling revalidatePath: parse the header value with URL when it looks like a full URL, require the path to start with '/', ensure the origin/host matches your application (or only accept internal-only values), and reject or default unknown/malformed values. Prefer a server-side source of truth for the path rather than the Referer/X-Pathname header when possible.
2. Whitelist allowed revalidation targets (explicitly allow only a small set of internal paths or path prefixes) and reject arbitrary values. For example, only allow '/', '/setup', and same-origin pathnames that match /^/([a-z0-9-]+(/)?)*$/i.
3. Rate-limit and audit revalidation endpoints/operations to mitigate potential DoS or abuse from automated calls that could repeatedly trigger revalidation.
4. Validate/whitelist frameworkIds against known framework IDs from your database or config before using them to initialize organization state. Do not rely solely on zod string type validation.
5. If you must persist user-supplied values like framework IDs or website, ensure they are normalized and later properly escaped/encoded at output time (escape HTML in templates or use framework auto-escaping). Consider validating website further (e.g., allowed schemes, allowed hosts) if needed.
6. Do not return raw error.message to clients. Return a generic client-facing error, and log the detailed error server-side (with correlation IDs if helpful). Example: return { success: false, error: 'Failed to create organization' } to client, and log the real error in server logs.
7. When extracting pathname from Referer or custom headers, prefer using the server's routing/metadata if available. If header-based fallback is necessary, canonicalize and sanitize the header value strictly.

🔴 packages/docs/openapi.json (HIGH Risk)

#	Issue	Risk Level
1	IDOR via X-Organization-Id header allowing org access tampering	HIGH
2	Inconsistent auth: session auth described but not declared in security schemes	HIGH
3	Unvalidated metadata string may enable stored XSS or injection	HIGH
4	Unvalidated URL fields (logo, website) may enable SSRF or phishing risks	HIGH
5	Sensitive fields (hasAccess, fleet flags) updateable without auth checks	HIGH

Recommendations:

1. Verify X-Organization-Id on the server against the authenticated session (cookies) and the authenticated user's organization membership. Reject requests where the header does not match the session-bound org.
2. Explicitly declare and enforce session-based authentication in components.securitySchemes (e.g., cookie or OAuth2/session scheme) and use security requirements per-operation to prevent relying solely on an optional header.
3. Treat metadata as structured JSON on the server: parse and validate against a strict schema, reject or canonicalize unexpected values, and always escape/encode any metadata when rendering in UIs to prevent stored XSS.
4. Validate and normalize URL fields (logo, website) server-side: enforce URL format, require schemes (https), enforce a domain whitelist (or deny server-side fetches to user-provided URLs), and do not perform untrusted server-side requests using these values without strict safeguards.
5. Protect sensitive fields (hasAccess, fleetDmLabelId, isFleetSetupCompleted) with role-based authorization checks. Only allow privileged roles to update them, require re-authentication/confirmation for destructive changes, and log/alert such changes.
6. Add server-side input validation for all endpoints (request body, query, path, headers). Prefer typed/structured schemas instead of free-form strings for data that contain nested JSON.
7. When issuing signed download URLs or building installers (device agent endpoints), ensure authorization checks tie the generated URL to the authenticated org and include short expirations and per-request nonces.
8. Implement auditing and alerting for sensitive operations (org delete, org update, setting hasAccess false/true, updating fleet flags) and retain sufficient logs to investigate potential abuse.

---

💡 Recommendations

View 3 recommendation(s)

1. Audit and parameterize all DB operations in apps/api/** (notably task-template.service.ts): reject/sanitize incoming IDs (e.g., enforce UUID format), avoid concatenating raw DTO fields into queries, and map update DTOs to an explicit whitelist of updatable columns before passing to the ORM/DB driver.
2. Verify and strictly validate any header-derived paths before using them with revalidation or routing (notably apps/app/src/actions/tasks/create-task-action.ts and apps/app/src/app/(app)/setup/actions/create-organization-minimal.ts): accept only known internal paths or route keys, normalize paths to remove protocols/hosts/.. segments, and reject unexpected values.
3. Search the codebase for hardcoded secrets (API keys, passwords, tokens) using pattern scans (e.g., regexes for common key prefixes and credential keywords) and remove/rotate any found; where secrets are detected, replace with secure secrets references and ensure they are not committed to source.

---

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

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ chasprowebdev
❌ github-actions[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[claudfuen]

🎉 This PR is included in version 1.56.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀