[dev] [Itsnotaka] daniel/policy-editor-ux

[github-actions]

This is an automated pull request to merge daniel/policy-editor-ux into dev.
It was created by the [Auto Pull Request] action.

[comp-ai-code-review]

Comp AI - Code Vulnerability Scan

⏳ Analysis in progress...

Reviewing 15 file(s). This may take a few moments.

---

Powered by Comp AI - AI that handles compliance for you | Reviewed Dec 4, 2025, 03:24 PM

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app	Building	Preview	Comment	Dec 4, 2025 3:26pm
portal	Ready	Preview	Comment	Dec 4, 2025 3:26pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV: 2 high NPM CVEs (xlsx@0.18.5: Prototype Pollution, ReDoS) and 1 low (ai@5.0.0 filetype bypass). Code also shows injection issues: stored XSS, Markdown/HTML injection, and an unvalidated DB param.

---

📦 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 5 file(s) with issues

🔴 apps/app/src/app/(app)/[orgId]/policies/[policyId]/editor/components/PolicyDetails.tsx (HIGH Risk)

#	Issue	Risk Level
1	Stored XSS: AI-proposed markdown saved via updatePolicy without sanitization	HIGH
2	Markdown/HTML injection in editor/diff/pdf from untrusted AI content	HIGH
3	No sanitization before markdownToTipTapJSON conversion	HIGH
4	No size or rate limits for AI-proposed content (DoS risk)	HIGH
5	No client-side authorization check before calling updatePolicy	HIGH

Recommendations:

1. Sanitize and validate markdown/HTML on server before persisting
2. Escape or sanitize TipTap JSON before rendering in UI
3. Enforce content size and rate limits on proposals
4. Perform server-side auth and authorization checks in updatePolicy
5. Show sanitized preview and require explicit user confirmation before apply

🟡 apps/app/src/app/(app)/[orgId]/policies/[policyId]/editor/components/ai/policy-ai-assistant.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated user input forwarded to sendMessage	MEDIUM
2	No client-side input sanitization or length checks	MEDIUM
3	Possible server-side injection if backend uses input unsafely	MEDIUM
4	Callback props (onScrollToDiff/close) may execute arbitrary code	MEDIUM

Recommendations:

1. Validate and sanitize input before calling sendMessage: enforce expected character sets, strip/escape dangerous characters if the backend expects plain text, and perform length checks (both min/max) on the client.
2. Enforce server-side validation and escaping: treat client input as untrusted, validate on the server, use parameterized queries/ORMs, escape output when rendering HTML, and apply context-appropriate encoding to prevent injection (SQL, HTML/JS, command injection).
3. Apply server-side rate limiting and size limits to protect against abuse and DoS; consider client-side UX limits (e.g., max textarea length) to provide quicker feedback to users.
4. Use content moderation or input sanitization for user-generated content that may be passed to LLMs or rendered as HTML; avoid dangerouslySetInnerHTML or ensure HTML is sanitized with a well-reviewed library before injecting.
5. Treat callback props as application-supplied behavior: ensure callbacks originate from trusted application code, validate their type/signature, and default to safe no-op handlers when appropriate. Don’t execute callbacks derived from untrusted input.
6. Log and monitor inputs and errors on the server to detect suspicious patterns or automated attacks; add tests that assert server rejects malformed/malicious inputs.

🟡 apps/app/src/app/(app)/[orgId]/policies/[policyId]/editor/tools/policy-tools.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation/limits for content, title, detail, reviewHint	MEDIUM
2	Potential XSS: user inputs echoed back without sanitization	MEDIUM

Recommendations:

1. Add zod constraints to the input schema: impose reasonable max lengths (e.g., .max(2000) for content, .max(200) for title, .max(500) for detail/reviewHint) and, where appropriate, character/format patterns.
2. Sanitize or escape all returned fields before rendering in any UI. Treat summary/title/detail/reviewHint as untrusted and HTML-escape them or render them as plain text.
3. If rendering markdown (content), use a markdown renderer that sanitizes output (e.g., markdown-it + DOMPurify, or sanitize-html) and strip dangerous tags/attributes. Do sanitization server-side or at the boundary before storing/serving.
4. Limit payload sizes and enforce server-side length checks to prevent resource exhaustion and large-payload abuse.
5. Add logging/validation failures and return safe error messages instead of echoing back raw input on errors.
6. Apply defense-in-depth: Content Security Policy (CSP), HTTP-only cookies, and proper output encoding for any place that injects these values into HTML/JS contexts.

🟡 apps/app/src/app/(app)/[orgId]/policies/[policyId]/editor/types/index.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Permissive content schemas (z.any()) in policyDetails & updatePolicy	MEDIUM

Recommendations:

1. Replace z.any() with explicit Zod schemas describing the allowed content shape. Example: define a PolicyContentItem schema (z.object({ type: z.enum([...]), text: z.string().max(2000), metadata: z.record(z.unknown()).optional() })) and use z.array(PolicyContentItem) for policyDetails.content and PolicyContentItem.optional() for updatePolicy.content.
2. If the content can be HTML/markup, explicitly allow only a safe subset. Prefer storing a sanitized canonical representation (or sanitize on input) and always escape or sanitize on render (e.g., DOMPurify on the client or a server-side sanitizer).
3. Use Zod preprocessing/parsing for dates coming from external input: e.g., z.preprocess((val) => new Date(String(val)), z.date()) to safely parse ISO date strings, and validate .toString()/isNaN checks to reject invalid dates.
4. Use .strict() on objects where appropriate to reject unexpected fields, and use limited string lengths, enums, and typed fields to prevent unexpected payloads and large nested objects.
5. Add validation/unit tests and runtime checks for incoming requests so that malformed or oversized content is rejected early. Log and monitor validation failures.
6. If you must accept arbitrary JSON, restrict it to a single well-documented field (e.g., rawBlob) and apply size limits, content-type checks, and thorough sanitization before rendering or downstream processing.

🟡 apps/app/src/app/api/policies/[policyId]/chat/route.ts (MEDIUM Risk)

#	Issue	Risk Level
1	SQL injection risk: unvalidated policyId in db.policy.findFirst	MEDIUM
2	Request messages accepted without validation or size limits	MEDIUM
3	No policy-specific authorization check for members	MEDIUM

Recommendations:

1. Validate and sanitize policyId before use: enforce expected format (e.g., UUID regex) and type-check it before passing to DB queries. Reject or normalize invalid values early.
2. Enforce finer-grained authorization on the policy: in addition to checking membership in the organization, verify member role/permissions for editing/viewing the specific policy (e.g., owner/editor/viewer). Log authorization decisions.
3. Validate and limit incoming messages: enforce per-message and total length/token limits, max number of messages, and reject or truncate messages that exceed limits. Apply content validation/sanitization to mitigate prompt injection (e.g., strip suspicious system-like directives if appropriate).
4. Apply rate limiting and request size caps at the API boundary to prevent resource exhaustion and abuse (per-user and per-organization limits).
5. Ensure DB usage is parameterized (use the ORM’s parameterized APIs) and avoid constructing raw query strings with user input. If raw queries are used elsewhere, convert them to parameterized/prepared statements.
6. Add server-side input validation schemas (e.g., zod/joi) for all request bodies and route params. Fail fast with clear errors.
7. Add monitoring/alerts for unusual usage patterns (large payloads, many requests) and for failed authorization attempts.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade affected packages: replace xlsx@0.18.5 with a patched release and bump ai to >=5.0.52 (the scan shows ai fixedIn 5.0.52). Re-run the vulnerability scan after upgrades to confirm fixes.
2. Sanitize and validate AI-proposed content server-side before persisting and before conversion to TipTap JSON: add a server-side sanitization step in the updatePolicy persistence path (reject or strip dangerous tags/attributes, enforce max lengths), and ensure any TipTap JSON inserted into the DOM is escaped or produced from a sanitized canonical representation.
3. Validate and type-check route params and DB inputs used in queries: add Zod (or equivalent) parsing for policyId (e.g., UUID regex) and request bodies in apps/app/src/app/api/policies/[policyId]/chat/route.ts, enforce per-message size limits, and use the ORM’s parameterized APIs (avoid passing unvalidated policyId/raw values into db.policy.findFirst) to prevent injection.

---

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