[dev] [Marfuen] mariano/tasks-stuff

[github-actions]

This is an automated pull request to merge mariano/tasks-stuff into dev.
It was created by the [Auto Pull Request] action.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app	Ready	Preview	Comment	Nov 6, 2025 8:12pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal	Skipped			Nov 6, 2025 8:12pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

Hardcoded API token found in client code and multiple code paths use unvalidated user-controlled IDs/params (including an API route that queries runs by automationId without auth/ownership checks).

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 10 file(s) with issues

🔴 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/actions/task-automation-actions.ts (HIGH Risk)

#	Issue	Risk Level
1	No auth/authorization checks before forwarding org/task actions	HIGH
2	User-supplied params/body forwarded to enterprise API without validation	HIGH
3	revalidateCurrentPath uses unvalidated referer/x-pathname header	HIGH
4	Console.log of URL may leak query params or sensitive info	HIGH
5	Enterprise API secret sent in header may be logged or leaked downstream	HIGH
6	Detailed API error messages returned to callers (information leak)	HIGH
7	No size limits or validation for uploaded scripts/messages (DoS risk)	HIGH
8	getAutomationRunStatus endpoint uses literal '${runId}' (incorrect URL)	HIGH

Recommendations:

1. Enforce authentication and per-org authorization on every server action. Verify the caller's session and that the user is permitted to act on the provided orgId/taskId/automationId before performing any side effects.
2. Validate and sanitize all inputs (orgId, taskId, automationId, runId, script content, chat messages, etc.) on the server. Enforce strict types, allowed character sets, and length limits. Reject or normalize unexpected values.
3. Restrict revalidateCurrentPath to only accept known internal paths. Do not use unvalidated Referer or custom headers to compute paths. Prefer deriving the path from server-side routing context or an explicit trusted parameter.
4. Remove or sanitize debug logs that may contain URLs or sensitive identifiers in production. Avoid logging full URLs with query strings that may contain sensitive data.
5. Avoid sending secrets in headers to third parties unless absolutely necessary. If required, ensure transport is trusted, and consider using short-lived tokens or signing mechanisms. Ensure downstream services and proxies do not log sensitive headers.
6. Do not propagate raw upstream error messages to clients. Log full errors server-side (with safeguards) and return generic error messages to callers. Sanitize or map error details before returning.
7. Enforce size and rate limits for uploads and message-saving endpoints. Validate script size, message count/size, and apply quotas per org/user to mitigate DoS and resource exhaustion.
8. Fix the getAutomationRunStatus URL interpolation — use a template literal or build the URL properly (e.g., /api/tasks-automations/runs/${runId} or use params correctly). Also validate runId before use.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/PublishDialog.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated user input sent to publishAutomation/executeAutomationScript	MEDIUM
2	Potential XSS if changelog is rendered unescaped elsewhere	MEDIUM
3	Displays raw error messages in toasts (info disclosure)	MEDIUM
4	Calls actions with automationIdRef.current without null/type checks	MEDIUM

Recommendations:

1. Validate and sanitize changelog on client and server
2. Validate orgId, taskId, automationId before use
3. Avoid showing raw error.message; show generic errors to users
4. Enforce server-side auth and input validation for publish/run actions
5. Add null/type checks for automationIdRef.current before calling actions

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/chat/message.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Potential XSS: message.parts rendered without sanitization	MEDIUM
2	Unchecked props (orgId/onInfoProvided/onSecretAdded) accept unvalidated input	MEDIUM
3	Use of 'any' casts masks type-safety and validation gaps	MEDIUM

Recommendations:

1. Sanitize/escape all user-controlled text before rendering. If rendering HTML, use a well-audited sanitizer (e.g., DOMPurify) and never pass raw HTML to dangerouslySetInnerHTML without sanitization.
2. Audit MessagePart implementation to ensure it does not use dangerouslySetInnerHTML or otherwise inject unsanitized content into the DOM. If it must render HTML, sanitize at the boundary where message parts are parsed/received.
3. Validate and canonicalize props that cross trust boundaries (orgId, onInfoProvided payloads, onSecretAdded inputs). Apply server-side validation and length limits, and perform minimal client-side checks (type/format/size).
4. Replace 'any' casts with stricter TypeScript types for message.parts and part shapes. Add runtime shape checks for incoming messages (e.g., using zod/io-ts) so malformed or malicious structures are rejected or sanitized.
5. Enforce message part size limits (max lengths) when ingesting/receiving messages to mitigate resource exhaustion and reduce attack surface for injected payloads.
6. Instrument logging/monitoring for unexpected content types or oversized messages so potential abuses are detected.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/evaluation/EvaluationCriteriaCard.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated input sent to updateEvaluationCriteria	MEDIUM
2	Possible SQL/command injection server-side via criteria	MEDIUM
3	Server error messages displayed via toast (info leak)	MEDIUM
4	No client-side length/size limits for criteria input	MEDIUM
5	No validation of automationId before sending	MEDIUM

Recommendations:

1. Validate and sanitize criteria server-side before use
2. Apply input length limits and content checks client-side
3. Avoid echoing raw server errors; show generic messages
4. Use parameterized queries / prepared statements server-side
5. Authenticate and authorize updateEvaluationCriteria calls

🔴 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/workflow/components/UnifiedWorkflowCard.tsx (HIGH Risk)

#	Issue	Risk Level
1	Hardcoded API token in image URL (pk_AZatYxV5QDSfWpRDaBxzRQ)	HIGH
2	Unvalidated external image URLs from integration.link may leak data or be abused	HIGH

Recommendations:

1. Remove the hardcoded token from client code immediately. Do not embed any API secrets or tokens in frontend bundles. Move secrets to server-side environment variables and only use server-side endpoints to mint short-lived, scoped tokens if the client truly needs one.
2. Rotate and revoke the exposed token immediately (assume compromise).
3. If the image-service requires a public key, ensure it is a truly public, revocable, limited-scope key and document that it is safe to be public — otherwise treat it as secret.
4. Validate and whitelist integration.link values on the server before persisting or returning them to the client. Only allow expected identifier formats (e.g., alphanumeric slugs) and/or a predefined set of domains. Reject or canonicalize inputs containing protocols (http://, https://), path traversal (../), or suspicious characters.
5. URL-encode any path segments derived from integration.link before concatenation so arbitrary characters cannot break the intended URL structure.
6. Proxy external image requests through a backend image endpoint (or use a signed URL service) so you control which external hosts are contacted and can strip/refuse sensitive headers and enforce size/time limits. Alternatively, use Next.js Image Optimization with allowed image domains configured and remove unoptimized=true.
7. Set referrerPolicy='no-referrer' (or an appropriate policy) on image elements to reduce leakage of page context to the image host, and consider appropriate cache-control headers.
8. Harden Content Security Policy (CSP) to restrict which image domains are allowed in the first place.
9. Audit EvaluationCriteriaCard and any component that renders external or user-provided content. Ensure any HTML is sanitized server-side or use safe React rendering (avoid dangerouslySetInnerHTML unless properly sanitized).

🔴 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/workflow/workflow-visualizer-simple.tsx (HIGH Risk)

#	Issue	Risk Level
1	Execution results/logs (possibly sensitive) sent to external AI	HIGH
2	Client-side only checks for execute/restore; no server-side auth shown	HIGH
3	useParams orgId/taskId/automationId can be tampered client-side	HIGH
4	Toast/error messages may expose internal error details	HIGH
5	restoreVersion called with unvalidated version parameter	HIGH

Recommendations:

1. Redact or strip sensitive fields (credentials, PII, tokens, full payloads) from execution results/logs before sending them to any external AI/chat model. Consider asking for explicit user confirmation and logging the export action.
2. Enforce authorization and input validation on the server for all actions (execute/run, restoreVersion, publish). Do not rely on client-side checks — server endpoints must verify the caller's orgId/taskId/automationId and permissions.
3. Treat all URL/JS params as untrusted. Validate and canonicalize orgId, taskId, automationId on the server and perform access-control checks there. Consider mapping client IDs to internal IDs rather than trusting raw URL values.
4. Avoid showing raw internal error messages or stack traces to end users. Return sanitized, user-friendly error messages to the client and log full errors only to server-side logs with restricted access.
5. Validate and authorize the requested version on the server when restoreVersion is called. Ensure the server checks that the version exists, belongs to the automation/org, and that the caller has restore permissions. Implement server-side rate limits and audit logging for destructive actions.
6. Add telemetry/audit trails and monitoring for any feature that sends data to external services (AI models). Maintain an allowlist of data types that can be exported and require review for any widening of that list.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/hooks/use-task-automation.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation: orgId/taskId/automationId used directly in API path	MEDIUM
2	Possible SQL/command injection on backend via unsanitized path params	MEDIUM
3	Path params not URL-encoded before making request	MEDIUM
4	Console logs expose backend errors/responses	MEDIUM

Recommendations:

1. Validate and sanitize orgId, taskId, automationId on the client before use (e.g., ensure expected format such as UUID via a regex) and, critically, enforce the same validations server-side.
2. URL-encode path segments before interpolation: use encodeURIComponent(taskId) and encodeURIComponent(automationId) when building the request path to avoid malformed requests or unintended routing.
3. Do not rely on client-side checks alone — ensure the backend uses parameterized queries / prepared statements and sanitizes req.params to prevent SQL or command injection. Review server handlers for direct usage of params in SQL or shell calls.
4. Remove or reduce logging of raw backend error objects in production. Log only non-sensitive error codes/messages and send sanitized error messages to the client. Use centralized logging with redaction for sensitive fields.
5. Add strict input validation at the API boundary (server): reject unexpected characters/lengths, validate IDs with precise schemas, and return 4xx for invalid parameters.
6. Consider adding unit/integration tests that send malicious path values (special chars, encoded payloads) to verify server rejects or safely handles them.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automations/[automationId]/overview/components/AutomationOverview.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated URL params used in API calls (orgId/taskId/automationId)	MEDIUM
2	Unsanitized description sent to API — stored XSS risk	MEDIUM
3	Sensitive actions callable from client without explicit auth checks	MEDIUM
4	Version parameter used without strict validation/allowlist	MEDIUM

Recommendations:

1. Enforce server-side validation for orgId, taskId, automationId (type checks, existence, ownership) and reject/403 on invalid or unauthorized values. Do not rely on client-side checks.
2. Sanitize/normalize description on the server before storing (strip dangerous HTML, or store only plain text). Where HTML is needed, use a robust HTML sanitizer (e.g., DOMPurify) on the server or before storing. Also ensure any places that render stored content use safe rendering (React escapes by default; avoid dangerouslySetInnerHTML unless sanitized).
3. Require server-side authorization for toggle/execute endpoints: verify the authenticated user has permission to perform the action on the specific org/task/automation. Implement principle of least privilege and fail closed.
4. Validate 'version' on the server: ensure it is an integer and that the requested version belongs to the automation (allowlist/enumeration), rejecting requests for versions that are not published/owned by that automation.
5. Add CSRF protections for state-changing endpoints and rate limiting for sensitive actions (toggle/execute/delete) to mitigate abuse.
6. Log and monitor execution/toggle actions and add audit trails (who ran what and when) so unauthorized attempts are detectable.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automations/[automationId]/overview/hooks/use-automation-runs.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated automationId in API path (/api/automations/{automationId}/runs)	MEDIUM
2	Potential IDOR if backend lacks per-automation authorization checks	MEDIUM

Recommendations:

1. Server-side: enforce authorization on /api/automations/:automationId/runs so a user can only access runs for automations they own or are allowed to view. Do not rely on client-side controls for access enforcement.
2. Server-side: validate and sanitize automationId (pattern, allowed chars, length, existence) and return 4xx for invalid IDs.
3. Client-side: check for presence/validity of automationId before calling useSWR (e.g., skip fetch when automationId is undefined or fails a simple pattern check).
4. Client-side: URI-encode the path segment (use encodeURIComponent(automationId)) when composing the request URL to avoid malformed requests.
5. Add rate limits and exponential backoff for polling (reduce 3s poll frequency, back off on repeated failures) to limit abuse and reduce load.
6. Log and monitor failed/forbidden accesses to detect abnormal enumeration or ID guessing attempts.

🔴 apps/app/src/app/api/automations/[automationId]/runs/route.ts (HIGH Risk)

#	Issue	Risk Level
1	No authentication/authorization: endpoint exposes runs publicly	HIGH
2	IDOR: automationId param allows access to other users' runs	HIGH
3	User input (automationId) used directly in DB query without validation	HIGH
4	Detailed error logged to console may leak sensitive info	HIGH

Recommendations:

1. Enforce authentication: require a valid session / JWT and reject unauthenticated requests before DB access.
2. Enforce authorization/ownership: verify the authenticated user is allowed to view the requested automationId (e.g., query the automation by id and ownerId or include ownerId in the findMany where clause).
3. Validate automationId: check format (e.g., UUID regex), allowed length/characters, and return 400 on invalid input.
4. Keep using the ORM parameterized APIs (as in this file) rather than raw SQL. If raw queries are ever used, ensure they use parameterization/prepared statements.
5. Avoid logging full error objects to standard logs in production. Log limited context and use structured logging/secure storage for debug info. Return a generic error message to clients.
6. Limit returned data and implement pagination/rate-limiting to reduce enumeration risk (e.g., ensure take/limit is small and consider cursors).
7. Add monitoring/alerts for anomalous access patterns to this endpoint (e.g., many different automationId requests from one actor).

---

💡 Recommendations

View 3 recommendation(s)

1. Remove the hardcoded token literal (pk_AZatYxV5QDSfWpRDaBxzRQ) from UnifiedWorkflowCard.tsx. Instead serve images via a backend endpoint that injects any required token server-side (frontend calls /api/images?integration=...) and never embed secrets in frontend bundles.
2. Harden /apps/app/src/app/api/automations/[automationId]/runs/route.ts: validate automationId (e.g., UUID regex), require and verify an authenticated session, then enforce ownership in the DB query (e.g., include ownerId/userId in the where clause) before returning runs. Return generic errors to clients on failure.
3. Sanitize and validate all path/query/body inputs before use or forwarding: URL-encode path segments (encodeURIComponent) when composing client requests, validate runId/orgId/taskId/automationId formats on entry, and reject or normalize unexpected values. Do not forward raw user-provided bodies/params to upstream/enterprise APIs without explicit allowlisting and validation.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Nov 6, 2025

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

Scan shows a hardcoded token in source (pk_AZatYxV5QDSfWpRDaBxzRQ) and multiple injection/exposure issues: unauthenticated runs endpoint, automationId used unsanitized (SQL/command risk), and unsanitized S3 keys (path traversal).

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 9 file(s) with issues

🔴 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/actions/task-automation-actions.ts (HIGH Risk)

#	Issue	Risk Level
1	Server secret used to call enterprise API without per-request auth/authorization	HIGH
2	Missing input validation for orgId/taskId/keys/scripts/messages before API calls	HIGH
3	Untrusted headers (referer/x-pathname) used to revalidate paths	HIGH
4	Console.log(url) may leak sensitive query params to logs	HIGH
5	Returning raw EnterpriseApiError messages leaks internal details	HIGH
6	Unsanitized S3 keys/params may allow path traversal or unauthorized access	HIGH

Recommendations:

1. Enforce per-request authentication and authorization: verify the caller's session, user identity and org membership before making any enterprise API calls. Map user/org context to the enterprise API calls or use per-user tokens where appropriate instead of relying solely on a single server secret.
2. Validate and sanitize all inputs server-side (orgId, taskId, automationId, keys, version, script content, messages, offsets/limits). Use strict allow-lists, length limits, and canonicalization. Reject or normalize suspicious values (e.g., path traversal sequences) before forwarding to enterprise API or S3.
3. Do not trust client-supplied headers for server-side control flows. For revalidatePath use a canonical server-side path derived from routing/context or verify the header against an allow-list of safe paths before calling revalidatePath.
4. Remove or redact sensitive information from logs. Avoid logging full URLs or query strings that may contain secrets or sensitive identifiers. If logging is required, mask or omit query params and never log secrets.
5. Mask internal error details returned to clients. Log full errors server-side for diagnostics, but return generic messages (e.g., 'Internal server error' or 'Operation failed') to callers. Only expose error codes that are intentionally public.
6. Tighten S3 / key handling: validate S3 keys against allowed prefixes, enforce per-org prefixes, and ensure the enterprise API performs authorization checks. Consider canonicalizing keys and rejecting path traversal patterns or keys that don't match expected schema.
7. Validate and sanitize responses from the enterprise API before persisting to the database. Treat external service response data as untrusted input.
8. Add rate limiting and auditing around sensitive operations (uploads, execute/trigger, publish/restore) to detect abuse.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/PublishDialog.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated URL params passed to publishAutomation/executeAutomationScript	MEDIUM
2	automationIdRef used without validation before server calls	MEDIUM
3	User changelog sent unsanitized (stored XSS risk)	MEDIUM
4	Server error messages displayed directly in toasts (info leak/XSS risk)	MEDIUM
5	No client-side authorization check before publish (server must enforce)	MEDIUM

Recommendations:

1. Enforce server-side validation for orgId, taskId, and automationId (reject malformed/unauthorized values). Never rely on client-side validation for access control.
2. Validate automationIdRef on the client before calling server actions (ensure it exists and matches expected format) and handle missing/invalid values gracefully to avoid unexpected server calls.
3. Sanitize and validate changelog server-side before storing or rendering. On output, escape HTML (or use a safe rendering pipeline) to prevent stored XSS. Optionally perform basic client-side validation (length, allowed characters) to improve UX.
4. Do not display raw server error strings directly to the UI. Return safe, categorized error codes/messages from the server and map them to user-friendly toasts on the client. If you must display server messages, ensure they are treated as plain text (escaped) and not rendered as HTML.
5. Ensure server enforces authorization for publish and execute actions. Optionally add client-side checks (feature gating/UI hiding) to improve UX, but never treat client-side checks as a security boundary.
6. Add defensive error handling for executeAutomationScript/publishAutomation responses (handle missing result.version, malformed responses) to avoid UI confusion or leaking internal details.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/evaluation/EvaluationCriteriaCard.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	User input sent raw to updateEvaluationCriteria (no validation)	MEDIUM
2	No length/size limits on criteria input (large payload/DoS risk)	MEDIUM

Recommendations:

1. Perform server-side validation and sanitization of the criteria in updateEvaluationCriteria (e.g., validate allowed characters, disallow unexpected control characters, enforce schema). Do not rely solely on client-side checks.
2. Enforce maximum length limits on the criteria both client- and server-side. Reject overly large payloads and consider rate limiting updates to prevent abuse/DoS.
3. Ensure the update endpoint requires authentication and proper authorization checks (verify the user can edit the given automation), and protect the endpoint against CSRF where applicable.
4. Log and monitor failed/abusive update attempts and add throttling/rate limits on the API to mitigate abuse.
5. On the server, use safe database access patterns (parameterized queries/ORM APIs) and sanitize any data before including it in downstream commands or API calls.

🔴 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/workflow/components/UnifiedWorkflowCard.tsx (HIGH Risk)

#	Issue	Risk Level
1	Hardcoded token in image URL (pk_AZatYxV5QDSfWpRDaBxzRQ)	HIGH
2	Unvalidated integration.link used to build external image URL (possible SSRF/exfiltration)	HIGH
3	next/image unoptimized client fetch may leak referrer or sensitive data	HIGH

Recommendations:

1. Remove the hardcoded token from source. Store tokens/keys in server-side environment variables and never commit them to the repo. Rotate the exposed token immediately.
2. Do not build external resource URLs from unvalidated input. Validate/whitelist integration.link values on the server (e.g., allow only known provider identifiers) and/or URL-encode and normalize the path components before use.
3. Proxy image requests through your server (or use Next.js Image Optimization) so the browser does not fetch the third-party URL directly. This lets you attach Authorization headers instead of putting tokens in query strings.
4. Avoid embedding tokens in query strings. Use short-lived signed URLs or send credentials in headers from a server-side proxy to prevent leakage via logs, Referer, or browser history.
5. Set strict Referrer-Policy (e.g., no-referrer or same-origin) and Content Security Policy to limit leakage and resource loading. Ensure responses from img.logo.dev cannot redirect to arbitrary hosts, or validate redirects.
6. If the token is exposed, rotate it and restrict its scope and permissions (principle of least privilege). Add monitoring/alerts for token misuse.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/workflow/workflow-visualizer-simple.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated URL params used in client actions/API calls (orgId/taskId/automationId)	MEDIUM
2	Sensitive execution logs/data sent to external AI via sendMessage	MEDIUM
3	Server error messages shown in toast without sanitization	MEDIUM

Recommendations:

1. Validate and canonicalize orgId/taskId/automationId on both client and server. On the client, ensure values parsed from useParams match expected patterns (e.g., UUID regex) before calling actions. On the server, re-validate and authorize every request — never trust client-provided IDs.
2. Enforce server-side authentication and authorization for restore/execute endpoints (restoreVersion, execute). Ensure these endpoints verify the caller's permissions for the given orgId/taskId/automationId and return minimal error detail.
3. Redact or sanitize execution logs, returned data, and error details before sending to external services or models. Avoid sending full payloads or logs to external AI without explicit user consent and policy controls.
4. Limit the information included in messages sent to third-party models. For debugging, send only non-sensitive, minimally sufficient context or an obfuscated/hashed identifier rather than raw data/logs.
5. Sanitize or normalize error messages before displaying in UI to avoid leaking internal details. Prefer generic user-facing messages and log full errors to a secure server-side log store accessible only to authorized personnel.
6. Ensure any UI toast/message rendering does not allow HTML injection. Use APIs that treat content as plain text (escape or avoid dangerouslySetInnerHTML).
7. Add telemetry/alerts for unexpected parameter values or unusual restore/execute activity to detect abuse of manipulated URL params.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/hooks/use-task-automation.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated URL params used directly in API request path	MEDIUM
2	Console logging API response may leak sensitive data	MEDIUM

Recommendations:

1. Validate and sanitize orgId, taskId, and automationId on the client before use (e.g., ensure they match expected patterns and lengths).
2. Encode path segments when building URLs: use encodeURIComponent(taskId) and encodeURIComponent(automationId) when composing the path.
3. Avoid relying solely on client-side checks — enforce strict server-side validation and authorization for orgId/taskId/automationId and return minimal error details to the client.
4. Remove or redact sensitive console.log statements that print API errors or response bodies. Use a gated logger that strips PII in production or log only non-sensitive error codes/messages.
5. Add input schema checks (e.g., zod/joi) and type guards on values derived from useParams to catch invalid/malicious values early.
6. Consider sending IDs in request body or headers where appropriate and performing additional server-side normalization/verification rather than directly interpolating URL segments.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automations/[automationId]/overview/components/AutomationOverview.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated URL params used in api.patch and executeAutomationScript	MEDIUM
2	User-supplied description sent to PATCH without sanitization	MEDIUM
3	Selected version sent to executeAutomationScript without validation	MEDIUM
4	Possible server-side command injection via execution inputs	MEDIUM
5	No explicit auth/permission checks visible for critical actions	MEDIUM

Recommendations:

1. Server-side: always validate and canonicalize orgId, taskId, automationId (e.g., UUID/expected format checks). Do not trust client-side routing values.
2. Server-side: validate and sanitize description input (strip/encode HTML, enforce length limits, deny prohibited characters if stored in contexts used for execution). Prefer storing raw text and encoding on render; apply output encoding for any HTML contexts.
3. Server-side: whitelist allowed automation versions and confirm the requested version exists and belongs to the specified automation before executing or queuing a run.
4. Server-side: if any input is used to invoke OS commands or spawn processes, avoid concatenating user input into shell commands. Use safe APIs (child_process.spawn with args array or equivalent), validate/escape inputs, or better yet perform operations via internal APIs without shelling out.
5. Enforce strong authentication and authorization checks on all endpoints (PATCH /v1/tasks/... and the execute endpoint). Verify the requester has permission for the org/task/automation and return 403 for unauthorized requests.
6. Add server-side rate limiting and logging/auditing for actions that trigger execution (tests, toggles, deletes).
7. On the client: perform basic input validation/formatting to provide better UX (but do not rely on it for security).
8. Consider CSRF protections for state-changing endpoints if cookies/session auth are used.

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automations/[automationId]/overview/hooks/use-automation-runs.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation: automationId used directly in API request	MEDIUM
2	SQL/command injection risk via automationId in /api/automations/:automationId/runs	MEDIUM

Recommendations:

1. Validate and sanitize automationId on the server (and optionally on the client) — enforce strict format (e.g., UUID regex) and reject/return 400 for invalid values.
2. On the server, always use parameterized queries or an ORM for any DB access that uses automationId. Never interpolate params directly into SQL.
3. Ensure the API route (/api/automations/:automationId/runs) enforces authentication and authorization to confirm the caller may access the requested automationId.
4. Do not pass automationId to shell/exec or eval. If any server logic must run external commands, validate and whitelist allowed IDs or use safe APIs that avoid shell interpretation.
5. On the client, check fetch response status (res.ok) and handle non-2xx responses gracefully instead of relying solely on res.json().

🔴 apps/app/src/app/api/automations/[automationId]/runs/route.ts (HIGH Risk)

#	Issue	Risk Level
1	No authentication/authorization: endpoint exposes runs to anyone	HIGH
2	IDOR: automationId used without ownership or permission check	HIGH
3	Missing input validation: automationId not validated or sanitized	HIGH
4	Potential data exposure: returns related automation name and runs	HIGH
5	Verbose error logging may leak sensitive internals	HIGH

Recommendations:

1. Require authenticated user and verify permissions before querying
2. Validate automationId format (e.g., UUID) and reject invalid input
3. Enforce ownership check: ensure user owns the requested automationId
4. Limit returned fields to only necessary data
5. Rate-limit endpoint and avoid verbose error details in responses

---

💡 Recommendations

View 3 recommendation(s)

1. Remove the hardcoded token from code immediately. Replace it with a runtime-config value and rotate the exposed token. Search the repo for that exact token and remove all occurrences.
2. Harden ID handling: validate automationId/orgId/taskId against a strict pattern (e.g., UUID regex) server-side, and use parameterized DB queries/ORM bindings (no string interpolation) and never pass IDs to shell/exec. In route.ts (/api/automations/[automationId]/runs) explicitly validate the automationId before any DB call and return 400 for invalid formats.
3. Canonicalize and validate storage keys before use: normalize S3/key paths (e.g., path.posix.normalize), reject keys containing ../ or that do not start with the expected per-org prefix, and enforce these checks both where keys are accepted and before any enterprise/S3 API call.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Nov 6, 2025

[claudfuen]

🎉 This PR is included in version 1.56.7 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀