[dev] [Marfuen] mariano/api-fix

[github-actions]

This is an automated pull request to merge mariano/api-fix 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	Building	Preview	Comment	Oct 14, 2025 6:48pm
portal	Building	Preview	Comment	Oct 14, 2025 6:48pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV/npm scan: no known CVEs. No hardcoded credentials reported. Static analysis flagged input-validation and injection-related risks in controllers, a client hook, and openapi.json.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 3 file(s) with issues

🟡 apps/api/src/tasks/automations/automations.controller.ts (MEDIUM Risk)

#	Issue	Risk Level
1	No validation on request bodies (create/update DTOs)	MEDIUM
2	Path params (taskId, automationId) used without explicit validation	MEDIUM
3	Query params limit/offset parsed without bounds or NaN handling	MEDIUM
4	OrganizationId header marked optional may allow missing org context	MEDIUM
5	Controller delegates to services without input sanitization checks	MEDIUM

Recommendations:

1. Enable Nest ValidationPipe and class-validator on DTOs
2. Validate and sanitize path params (e.g. UUID format) before use
3. Clamp limit/offset, handle parseInt NaN, and enforce sensible max
4. Require OrganizationId for session auth or fail fast when absent
5. Enforce server-side authorization and input checks in services

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

#	Issue	Risk Level
1	Unvalidated orgId/taskId used in API path	MEDIUM
2	Unvalidated params used in SWR cache key (cache poisoning/data leakage)	MEDIUM
3	Throws raw server error to UI, risking info leakage	MEDIUM

Recommendations:

1. Validate and normalize orgId and taskId on the client before use (e.g., enforce UUID or expected slug regex). Reject or canonicalize unexpected values.
2. Encode path segments when building URLs: use encodeURIComponent(taskId) and encodeURIComponent(orgId) in the request path to avoid injection of special characters into the path.
3. On the client, avoid throwing or displaying raw server error strings. Map server error details to a generic user-facing message (e.g., 'Failed to load automation runs') and send full error details to a server-side log or error-tracking system.
4. On the server, enforce strict validation of taskId/orgId and tenant authorization: ensure the requesting org is authorized for the requested taskId and validate formats/lengths to prevent abuse.
5. Use structured SWR keys that do not interpolate raw inputs into a single string. Prefer arrays of validated values (you already use an array; ensure elements are validated). If including string prefixes, avoid injecting raw user input into a single concatenated key — e.g., keep keys like ['task-automation-runs', validatedOrgId, validatedTaskId].
6. Add defensive checks and error handling around the api.get response: ensure the response shape is validated before using error/data and do not propagate server stack traces or raw messages to consumers.

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

#	Issue	Risk Level
1	Unvalidated X-Organization-Id header—possible IDOR / auth bypass	HIGH
2	PATCH allows updating hasAccess and sensitive flags—privilege escalation risk	HIGH
3	Session auth documented but not defined in security schemes—auth misconfiguration	HIGH
4	No input validation (length/pattern/format) on request body fields	HIGH
5	metadata is a raw JSON string—stored XSS / JSON injection risk	HIGH
6	logo and website lack URL/URI validation—javascript: URI risk	HIGH
7	No explicit protections against SQL/command injection if inputs used unsafely	HIGH

Recommendations:

1. Enforce server-side authoritative organization identification. Treat X-Organization-Id as advisory only (or ignore it) and derive organization from the authenticated session/API key; validate that the authenticated principal is allowed to act on the requested org.
2. Restrict updates to sensitive fields (e.g., hasAccess, isFleetSetupCompleted, fleetDmLabelId) to high-privilege roles only (admin/system). Add explicit checks/authorization middleware for PATCH endpoints.
3. Explicitly model all supported authentication methods in OpenAPI securitySchemes (e.g., cookie/session, OAuth2) and require appropriate security per operation. Ensure server-side authentication logic matches the documented options.
4. Add strict server-side validation for all request inputs: enforce maxLength, patterns, type/format (email, uri, date-time), required fields, and any enum constraints. Do not rely solely on the OpenAPI doc—validate at the API layer.
5. Change metadata to a structured object schema in the API (or validate/parsestring safely on the server). If storing user-provided strings that may include HTML/JS, sanitize or encode before rendering in any UI to prevent stored XSS.
6. Validate logo and website fields as URLs (use a safe URL parser). Reject or normalize javascript: and other dangerous schemes. Consider allowing only http/https and enforce maxLength.
7. Adopt safe data access patterns: use parameterized queries/ORM bindings (no string concatenation into SQL), avoid exec/eval with user data, and sanitize any shell/command inputs. Add code-level review and tests for injection vectors.

---

💡 Recommendations

View 3 recommendation(s)

1. Add and enforce explicit input validation/sanitization in API code: enable Nest ValidationPipe and class-validator on DTOs used by apps/api/src/tasks/automations/* and apps/api/src/automation/*; validate path params (e.g., UUID regex) and clamp/parse query params (limit/offset) to avoid NaN or oversized values.
2. Treat X-Organization-Id and other client-provided identifiers as untrusted in server code: validate formats and require server-side authorization checks before using orgId/taskId (files flagged include apps/api/* controllers and packages/docs/openapi.json). Fail fast when required org context is missing.
3. Harden OpenAPI-exposed fields and PATCH operations: disallow or server-authorize updates to sensitive flags (hasAccess, isFleetSetupCompleted) and validate/parse metadata as a structured object; enforce URL/URI format checks for logo/website to prevent injection/XSS (apply fixes in packages/docs/openapi.json and corresponding request handlers).

---

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

[claudfuen]

🎉 This PR is included in version 1.56.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀