[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 5, 2025 11:26pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal	Skipped			Dec 5, 2025 11:26pm

[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

Adds a new Integration Platform (providers, OAuth, checks runtime, APIs, DB schema) and migrates app UI, cloud tests, and people sync to it.

• Platform Backend:
  • Introduces @comp/integration-platform package with core types, registry, manifests (aws, gcp, azure, github, google-workspace, vercel, linear, rippling), variables, and runtime (createCheckContext, runCheck, runAllChecks).
  • Adds extensive API endpoints under /v1/integrations/* for OAuth, connections, variables, checks, task mappings, webhooks, and sync (incl. employee sync and check runs).
  • Implements handlers/helpers for provider APIs (e.g., AWS STS/IAM/SecurityHub, GCP SCC/IAM/Monitoring, Azure Security/Monitor/IAM, GitHub rules/rulesets).
• Data Layer:
  • New Prisma models/migrations: IntegrationProvider, IntegrationConnection, credential versions, runs (IntegrationRun, IntegrationCheckRun/Result), findings, OAuth state/apps, platform credentials; user isPlatformAdmin flag.
• App Frontend:
  • Replaces integrations grid with PlatformIntegrations and new dialogs (ConnectIntegrationDialog, ManageIntegrationDialog).
  • Cloud Tests UI refactor to use platform providers, run checks, disconnect via hooks; results formatting tweaks.
  • People > Team Members: server-side employee sync status, UI to trigger Google Workspace/Rippling sync; deactivated member indicators/filters.
• Routing/Actions:
  • Switches many actions from @/jobs/* to @/trigger/* paths; adds questionnaire single-question action.
• Misc/Config:
  • Adds NEXT_PUBLIC_API_URL server API client, tsconfig path updates, dependency updates, and a manifest validator script.

^{Written by Cursor Bugbot for commit c386831. 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.