[dev] [Marfuen] mariano/integrations-architecture

[github-actions]

This is an automated pull request to merge mariano/integrations-architecture 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	Error			Dec 3, 2025 10:54pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal	Skipped			Dec 3, 2025 10:54pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV scan: 2 High CVEs in xlsx@0.18.5 (Prototype Pollution, ReDoS) and 1 Low CVE in ai@5.0.0 (filetype whitelist bypass, fixed in 5.0.52).

---

📦 Dependency Vulnerabilities

🟠 NPM Packages (HIGH)

Risk Score: 8/10 | Summary: 2 high, 1 low CVEs found

Package	Version	CVE	Severity	CVSS	Summary	Fixed In
xlsx	0.18.5	GHSA-4r6h-8v6p-xvw6	HIGH	N/A	Prototype Pollution in sheetJS	No fix yet
xlsx	0.18.5	GHSA-5pgg-2g8v-p4x9	HIGH	N/A	SheetJS Regular Expression Denial of Service (ReDoS)	No fix yet
ai	5.0.0	GHSA-rwvc-j5jr-mgvh	LOW	N/A	Vercel’s AI SDK's filetype whitelists can be bypassed when uploading files	5.0.52

---

🛡️ Code Security Analysis

View 3 file(s) with issues

🔴 .cursor/rules/trigger.advanced-tasks.mdc (HIGH Risk)

#	Issue	Risk Level
1	Unvalidated payload.dataUrl used in fetch -> SSRF/remote fetch abuse	HIGH
2	Exposing accessToken to client-side useTaskTrigger (secret leakage)	HIGH
3	Tags built from payload.userId without validation or sanitization	HIGH
4	Queue names derived from payload.userId without validation	HIGH
5	Fetching largeData via payload.dataUrl without size/time limits (DoS)	HIGH
6	Unvalidated item.id stored in metadata may leak or inject content	HIGH

Recommendations:

1. Validate and allowlist payload.dataUrl before fetching: parse the URL, enforce https/http only if appropriate, disallow file:// and data://, and block internal/private IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, link-local).
2. Perform server-side resolution checks for DNS rebinding and enforce hostname allowlists. Consider fetching external resources from a hardened proxy that enforces network egress rules and inspects responses.
3. Never pass long-lived or sensitive access tokens to client-side code. Trigger tasks from server-side endpoints or use short-lived, least-privilege tokens with strict scopes and expiry if any client-side credential is unavoidable.
4. Sanitize and validate any user-derived tag names and queue names: use a strict regex (allowed chars), enforce length limits (e.g., 1-64 chars), maximum number of tags (max 10), and normalize/escape unsafe characters. Reject or canonicalize invalid values instead of interpolating raw user input.
5. Limit dynamic resource creation based on user input (e.g., per-user queues). Enforce quotas and rate limits to prevent resource/queue explosion and abuse; map user IDs to a safe canonical identifier instead of using raw values in names.
6. When fetching external payloads, enforce timeouts, connection limits, and maximum response sizes. Stream-and-limit responses and abort when exceeding byte limits. Use libraries or proxy layers that support max body size and timeouts.
7. Treat metadata fields (like item.id) as untrusted. Validate length and allowed characters, strip control characters, and escape or encode metadata before storing or rendering in any UI to avoid injection/XSS or leaking sensitive identifiers.
8. Add logging/monitoring and alerts for unusual patterns (many distinct queue names, many unique tags, repeated large external fetches) to detect abuse early.
9. Where feasible, move external fetches and sensitive operations into a hardened backend service that enforces the above checks and applies additional security controls (scanning, content-type checks, sandboxing).
10. Document and enforce these validations as part of input handling guidelines and include unit/integration tests that cover malicious/edge-case inputs (e.g., private IPs, oversized files, control characters).

🟡 .cursor/rules/typescript-rules.mdc (MEDIUM Risk)

#	Issue	Risk Level
1	Unsafe type assertions of API responses (e.g., ...json() as Task)	MEDIUM
2	Double or legacy assertions (as unknown as Type, <Type>value)	MEDIUM
3	Use of any disabling type checks (e.g., const data: any)	MEDIUM
4	Non-null assertions (!) without prior runtime checks	MEDIUM
5	Use of @ts-ignore / @ts-expect-error to hide errors	MEDIUM
6	Trusting localStorage / JSON.parse without schema validation	MEDIUM

Recommendations:

1. Validate all external input (API responses, localStorage, JSON.parse results) with runtime schemas (e.g., zod, io-ts) before casting to app types.
2. Replace any with unknown and implement proper type narrowing or use generics for reusable code. Enable noImplicitAny and strict compiler options.
3. Eliminate unsafe assertions (as Type, as unknown as Type, <Type>value) — instead use runtime checks/type guards or schema parsing and only assert in the limited exceptions (tests, DOM refs after checks, event target narrowing).
4. Remove @ts-ignore / @ts-expect-error comments; fix underlying type issues or narrow types correctly. Reserve these only in exceptional, documented cases in tests.
5. Avoid non-null assertions (!) without explicit runtime checks. Use guards/early returns, optional chaining, or validated values before dereferencing.
6. Add automated lint rules and pre-commit checks (eslint/@typescript-eslint rules forbidding any, unsafe assertions, @ts-ignore) and include schema validation in integration tests.

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

#	Issue	Risk Level
1	IDOR via X-Organization-Id header allowing unauthorized org access	HIGH
2	Unrestricted updates to sensitive fields (hasAccess, fleetDmLabelId)	HIGH
3	Inconsistent auth spec (security lists apikey but description allows cookies)	HIGH
4	Insufficient input validation for header/body (no patterns or limits)	HIGH
5	metadata is a raw JSON string — stored XSS or injection risk	HIGH
6	No URL format enforcement for logo/website fields	HIGH
7	Potential SQL injection if inputs used in queries without sanitization	HIGH

Recommendations:

1. Require server-side authorization that binds X-Organization-Id to the authenticated session; do NOT trust a client-supplied organization header for access control. Validate the org id against session or API key ownership on every request.
2. Remove sensitive flags (e.g., hasAccess) and internal IDs (fleetDmLabelId) from client-writable DTOs. Only allow privileged server-side or admin-only endpoints to change these fields and enforce RBAC checks.
3. Clarify and enforce explicit authentication schemes in the OpenAPI spec: declare both apiKey and cookie/session security schemes (or separate schemes) and declare which endpoints support which schemes. Ensure implementation matches the spec.
4. Add strict input validation for all headers, path params, query params and request bodies: types, formats, maxLength/minLength, regex patterns where applicable and explicit enums. Reject or sanitize unexpected additionalProperties.
5. Model metadata as a structured JSON object with a server-side JSON schema (not a free-form string). Validate and sanitize the metadata fields server-side before storing or rendering to prevent stored XSS or injection.
6. Enforce URL formats for logo/website fields (use format: uri or a strong regex) and validate and canonicalize URLs server-side. Reject or sanitize non-URL values.
7. Use parameterized queries / prepared statements or an ORM with query parameterization for all DB access. Treat any input from req.body/req.query/req.params as untrusted; validate/normalize before using in queries to eliminate SQL injection risk.
8. For file upload fields (base64 data), validate MIME types, size limits, and store blobs in object storage rather than directly in DB when possible. Scan or sanitize content before serving.
9. Escape or sanitize any user-provided content before including it in HTML responses or generated PDFs. Use safe templating/HTML-encoding libraries to prevent XSS.
10. Add logging, monitoring and rate limits around endpoints that accept org IDs and bulk operations to detect abuse or mass enumeration.
11. Ensure signed URL generation checks authorization (that the requester is allowed to access the attachment) and that signed URLs expire and are scoped to a specific object.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade xlsx (remove or update 0.18.5) to a release that patches GHSA-4r6h-8v6p-xvw6 and GHSA-5pgg-2g8v-p4x9; update package.json and lockfile, run tests, and re-scan OSV advisories to confirm the fix.
2. Update ai from 5.0.0 to at least 5.0.52 (fixedIn provided) in package.json/lockfile, re-install and verify file-upload handling behavior in code paths that use this SDK.
3. If you cannot upgrade immediately, stop parsing untrusted .xlsx files with the vulnerable xlsx version (return an error or defer processing), and add server-side validation/whitelisting of input files before handing them to the xlsx parser to reduce immediate exposure.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Dec 3, 2025