[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 9, 2025 0:05am
portal	Ready	Preview	Comment	Dec 9, 2025 0:05am

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV scan found 2 high and 1 low npm vulnerabilities: [email protected] (Prototype Pollution, ReDoS) and [email protected] (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 4 file(s) with issues

🔴 .cursor/rules/data-fetching.mdc (HIGH Risk)

#	Issue	Risk Level
1	Trusting client-supplied orgId without server-side auth checks	HIGH
2	Using orgId from params to set X-Organization-Id header enables spoofing	HIGH
3	No server-side validation of orgId and mutation inputs	HIGH
4	Unsanitized mutation inputs may allow SQL injection on backend	HIGH
5	Server-fetched initialData is hydrated to client and may leak sensitive data	HIGH
6	apiClient used in client may expose Bearer tokens to XSS attacks	HIGH

Recommendations:

1. Perform server-side authorization: verify the authenticated user/session has access to the requested orgId before returning any data. Do not rely solely on the orgId supplied in the URL or request headers.
2. Enforce access control on the backend for every API endpoint: ignore client-provided X-Organization-Id unless the server has validated that the requesting user belongs to that organization.
3. Validate and sanitize all inputs server-side (organization IDs, mutation bodies, query params). Use strict typing/validation libraries (e.g., zod, Joi) and canonicalization where appropriate.
4. Harden backend data layer against injection: use parameterized queries / ORM query builders, avoid concatenating user input into SQL, and apply prepared statements for all DB operations that use user input.
5. Filter/omit sensitive fields before hydrating initialData to the client. Send only the minimal fields necessary for the client UI and provide separate server endpoints for sensitive data with stricter checks.
6. Avoid storing or exposing long-lived tokens in JS-accessible storage. Prefer httpOnly, secure cookies for auth tokens or use server-side proxies for requests that require tokens. If tokens must be handled client-side, ensure strong XSS protections (CSP, input sanitization, escaping, code audits).

🟡 .cursor/rules/forms.mdc (MEDIUM Risk)

#	Issue	Risk Level
1	Relies solely on client-side Zod validation	MEDIUM
2	Server error messages may be displayed unsanitized	MEDIUM
3	No CSRF protection shown when submitting forms	MEDIUM

Recommendations:

1. Perform server-side validation for every input. Mirror or re-apply Zod schemas (or equivalent validation) on the server before processing or persisting data. Never trust client-side validation alone.
2. Validate and enforce input lengths and types on the server (max length, allowed chars, numeric ranges). Reject or truncate inputs that exceed limits server-side.
3. Sanitize/escape any error messages or strings returned by the server before rendering in the UI. Do not insert unsanitized server strings into the DOM, and avoid dangerouslySetInnerHTML unless content is sanitized with a robust HTML sanitizer (e.g., DOMPurify) and a strict policy.
4. When showing server errors, prefer structured error objects (field -> message) and avoid rendering raw server-provided HTML. Encode output using the framework's escaping mechanisms.
5. Implement CSRF protections for state-changing endpoints: use anti-CSRF tokens (synchronizer token pattern or double-submit cookie), require a custom header (e.g., X-CSRF-Token) for AJAX requests, and set SameSite=strict/lax on cookies as appropriate.
6. Use secure defaults for cookies (HttpOnly, Secure, SameSite) for auth/session cookies.
7. Add Content Security Policy (CSP) and other HTTP hardening headers (e.g., via Helmet) to reduce risk from XSS that could enable CSRF or leak error messages.
8. Log and monitor validation/CSRF failures, and return minimal error information to clients (avoid detailed internal error traces).

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

#	Issue	Risk Level
1	Unvalidated payload.dataUrl fetched directly (SSRF/remote fetch risks)	HIGH
2	Client receives accessToken prop in UI (secrets exposed to users)	HIGH
3	User input used to form queue/tag names without sanitization (injection/DoS)	HIGH
4	Error logging prints full error objects (may leak credentials)	HIGH
5	No input validation/schema checks on task payloads	HIGH

Recommendations:

1. Validate and whitelist payload.dataUrl values before fetching. Block internal/private/localhost IPs and non-allowed hostnames. Prefer server-side proxying of fetches or require presigned URLs pointing to trusted storage for large files.
2. Do not send long-lived secrets (access tokens, API keys) to the frontend. Use server-side invocation, short-lived/ephemeral tokens, or an auth flow that mints per-session tokens with minimal scope.
3. Sanitize and validate any user-derived values used in tags, queue names, or identifiers. Enforce allowed character sets, max lengths, and restrict dynamic naming to patterns with an allowlist of prefixes. Rate-limit and quota such constructs to mitigate DoS/resource exhaustion.
4. Avoid logging full error objects that may contain sensitive data. Redact or remove sensitive fields before logging (tokens, credentials, PII). Use structured logging with explicit fields and sanitization hooks in centralized logger/tracer implementations.
5. Enforce input schemas for all task payloads (e.g., zod, joi, ajv). Validate and coerce payloads at the task entry point, reject unknown/extra fields, and fail fast on malformed data. Use typed contracts and runtime validation for any data that comes from external callers.

🟡 apps/api/packages/docs/openapi.json (MEDIUM Risk)

#	Issue	Risk Level
1	Auth mismatch: operation documents session auth but security only enforces apikey	MEDIUM
2	Optional X-Organization-Id header can enable IDOR if not validated	MEDIUM
3	PATCH allows updating sensitive flags (hasAccess, isFleetSetupCompleted)	MEDIUM
4	metadata is a raw JSON string; unsafe parsing could enable injection	MEDIUM
5	Missing validation/format constraints for URLs, slug and IDs	MEDIUM
6	Cookie-based session auth without CSRF controls increases CSRF risk	MEDIUM
7	No request size limits for body; large payloads may enable DoS	MEDIUM

Recommendations:

1. Define and declare the session/cookie security scheme in components.securitySchemes (e.g., cookieAuth) and reference it in endpoints that support session auth so the OpenAPI security requirements match documented behavior.
2. Make X-Organization-Id handling explicit: require it only where appropriate, and always validate it against the authenticated session (reject requests where header org ID does not match session's org). Enforce server-side org ownership checks to prevent IDOR.
3. Limit which users/roles can update sensitive organization fields. Move hasAccess, isFleetSetupCompleted and similar flags behind admin-only endpoints or require an elevated role/approval workflow. Document RBAC in the API spec.
4. Change metadata from an unconstrained string to a proper JSON object schema (or a string with strict JSON schema validation). Parse JSON safely (no eval), validate against a schema, and sanitize/escape fields before use in downstream contexts.
5. Add explicit validation rules and formats in the OpenAPI schemas: URL format for website/logo, slug pattern (regex), ID formats, maxLength constraints, and stricter types (avoid using generic object where a shape is known). Use additionalProperties: false where appropriate.
6. For cookie-based session auth explicitly document and enforce CSRF mitigations: require sameSite=strict/lax cookies, include anti-CSRF tokens for state-changing endpoints, and validate Origin/Referer headers for browser requests.
7. Specify request size limits and payload constraints in the API and enforce them server-side (max bytes, max array lengths, file size limits). Add rate limiting and request-body validation to mitigate large-payload DoS.
8. Ensure generated signed URLs and file download endpoints validate requester authorization and apply short expirations and secure S3 ACLs; avoid returning long-lived or unscoped download URLs.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade xlsx (0.18.5) to a patched release that addresses GHSA-4r6h-8v6p-xvw6 (Prototype Pollution) and GHSA-5pgg-2g8v-p4x9 (ReDoS); after upgrading, run parsing-related tests against untrusted/edge-case Excel files.
2. Upgrade ai from 5.0.0 to >=5.0.52 (addresses GHSA-rwvc-j5jr-mgvh) and add server-side file-type/content validation (magic-bytes/content-sniffing) before handing uploads to the SDK.
3. Harden file-handling code that invokes xlsx or the ai SDK: enforce strict max file size and complexity limits, reject malformed/suspicious spreadsheets, and sanitize any parsed content before further processing to reduce Prototype Pollution and ReDoS exposure.

---

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

[cursor]

PR Summary

Introduce a full integration platform (manifests, APIs, runtime, UI) with persistence, and wire app to run checks and employee sync.

• Integration Platform (new @comp/integration-platform):
  • Runtime (check context/runner), manifest registry/validators, and task mappings.
  • Manifests and checks for github, google-workspace, gcp, aws, azure, linear, vercel, rippling.
• Backend:
  • New REST endpoints under /v1/integrations for OAuth, connections, variables, checks, runs, sync.
  • Prisma: add integration providers/connections/credentials/runs/findings/check runs/variables, OAuth apps, platform credentials, User.isPlatformAdmin, org employee sync provider.
• Frontend:
  • Admin area (/admin/integrations) to configure platform OAuth credentials.
  • Task UI: surface integration checks and history; Vercel/GitHub etc.
  • People: deactivated member UI tweaks; add employee sync source selector and trigger.
• Cloud Tests & App:
  • Migrate cloud provider findings to new integration platform (with legacy fallback).
• Docs:
  • Add integration docs (overview, writing, auth, variables, self-hosting OAuth).
• Misc:
  • Replace jobs paths with trigger tasks; TS config/deps updates.

^{Written by Cursor Bugbot for commit 59b19f7. This will update automatically on new commits. Configure here.}

[graphite-app]

Graphite Automations

"Auto-assign PRs to Author" took an action on this PR • (12/05/25)

1 assignee was added to this PR based on Mariano Fuentes's automation.

[cursor]

Bug: Missing @comp package copy in buildspec.yml for Docker build

The Dockerfile adds COPY node_modules/@comp ./node_modules/@comp and package.json adds the @comp/integration-platform dependency, but buildspec.yml was not updated to copy @comp packages to the Docker build directory. The buildspec only copies @trycompai packages (lines 60-67). Since the API imports from @comp/integration-platform (confirmed in multiple controller files), the Docker container will fail at runtime because the package won't be present in the image built by CodeBuild/AWS.

Additional Locations (1)

• apps/api/package.json#L11-L12