[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.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app	Ready	Preview	Comment	Dec 4, 2025 2:43pm
portal	Ready	Preview	Comment	Dec 4, 2025 2:43pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV: xlsx@0.18.5 — GHSA-4r6h (Prototype Pollution, HIGH) and GHSA-5pgg (ReDoS, HIGH); ai@5.0.0 — GHSA-rwvc (LOW). Code: unsanitized AI->TipTap (persistent XSS) and unvalidated messages/policyId (IDOR).

---

📦 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	AI-proposed content applied without sanitization (persistent XSS risk)	HIGH
2	markdownToTipTapJSON output not validated before updatePolicy call	HIGH
3	Potential IDOR: policyId used directly in client API endpoints without server auth checks	HIGH

Recommendations:

1. Sanitize and schema-validate AI-produced TipTap JSON before persisting. For example, run the converted jsonContent through an allowlist schema validator and a sanitizer (or validateAndFixTipTapContent) before calling updatePolicy.
2. Do not directly persist AI output returned from markdownToTipTapJSON. After conversion, call validateAndFixTipTapContent (or equivalent) and enforce server-side validation of the TipTap document shape and allowed marks/nodes.
3. Harden server-side authorization on all policy endpoints (/api/policies/:policyId/*). The client passing policyId is expected; ensure the server verifies the current user is authorized to view/modify that specific policy (prevent IDOR).
4. When applying AI-proposed changes keep the explicit review step (diff + Apply button). Additionally, show rendered preview with escaped content and warn users about AI-generated content. Log/alert large automated updates for audit.
5. Apply output-encoding/escaping when rendering TipTap content in the browser and use CSP to mitigate any unexpected script injection vectors.

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

#	Issue	Risk Level
1	Unsanitized user input sent to sendMessage	MEDIUM
2	No client-side input validation or length limits	MEDIUM
3	Possible server-side injection if sendMessage forwards raw input	MEDIUM
4	Displaying errorMessage directly may leak sensitive server info	MEDIUM

Recommendations:

1. Treat all client input as untrusted. Perform validation and sanitization on the server side before using or storing input from sendMessage.
2. Add client-side constraints to improve UX and reduce accidental large payloads: enforce a reasonable maxlength on the textarea, trim input, and reject empty/whitespace-only submissions.
3. On the server, validate and canonicalize input, use parameterized queries/ORMs for any DB usage, avoid concatenating user input into command lines or eval(), and escape or whitelist values used in sensitive contexts.
4. Avoid returning raw internal error messages to the client. Log detailed errors server-side and return a generic, user-friendly error message. If you must surface specific errors, sanitize them to remove stack traces, SQL queries, secrets, or internal paths.
5. Implement rate limiting, throttling, and request size limits to mitigate abuse from automated or malicious clients.
6. If you need richer client-side validation (e.g., to guide users), still enforce identical rules server-side — client-side checks are only UX protections, not security controls.

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

#	Issue	Risk Level
1	Unvalidated content (z.any) in policyDetails and updatePolicy	MEDIUM
2	createdAt/updatedAt use z.date() without coercion from strings	MEDIUM

Recommendations:

1. Replace z.any() with an explicit, strict schema for policy content. Define the expected shape for each content item (e.g., z.object({ type: z.enum([...]), text: z.string().max(10000), ... })) and validate arrays with z.array(yourContentSchema).
2. Enforce size and shape constraints: limit array length (z.array(...).max(n)), enforce field length limits (z.string().max(...)), and use specific types instead of any to prevent unexpected objects or executable payloads.
3. Sanitize/normalize content at ingestion and before rendering/storing. For HTML or rich text, run server-side sanitization (e.g., DOMPurify on server or an equivalent sanitizer) and/or escape on render. For non-HTML structured content, validate and strip dangerous fields.
4. Accept and coerce ISO date strings if inputs come as strings. Use z.coerce.date() or preprocess incoming values to parse strings to Date objects (e.g., z.preprocess((v) => new Date(v as string), z.date())). Validate date ranges if required.
5. Ensure schemas are actually applied where data enters the system (API handlers, DB writes). Validate req.body / incoming payloads against these Zod schemas before using/storing the data.
6. Add tests and logging for validation failures so malformed or malicious payloads are rejected and observable.
7. Review authorization checks in the code paths that consume these schemas to ensure only authorized users can read or modify policies (the types file defines errors but does not enforce auth).

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

#	Issue	Risk Level
1	policyId from URL used directly in DB query	MEDIUM
2	req.json() messages used without validation before model conversion	MEDIUM
3	No size/length limits on messages (DoS risk)	MEDIUM
4	console.error may leak sensitive details to logs	MEDIUM

Recommendations:

1. Validate and canonicalize policyId before using in DB queries (e.g., enforce UUID pattern or internal ID format). Prefer explicit typed parameters and/or use ORM parameterization (avoid string-concatenated queries).
2. Validate the messages payload schema (types, allowed fields) and sanitize content before passing to convertToModelMessages/openai. Implement server-side checks to reject unexpected shapes or fields.
3. Enforce limits on message count and per-message size (bytes/characters). Return a 413 or 400 for oversized payloads. Consider rate limiting and request throttling per user/org to mitigate DoS.
4. Avoid logging raw error objects or user-provided data. Sanitize or redact sensitive fields before logging. Consider structured logging with minimal context and a correlation ID for support.
5. Apply least-privilege for DB access (use a role that can only read the needed policy fields), and ensure the ORM/DB layer uses parameterized queries. Add layered checks: confirm organizationId matches session and that member authorization is enforced (already present but keep asserts).

🟡 packages/ui/src/components/ai-elements/prompt-input.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated uploads: no consistent type/size checks; SVG may allow script execution	MEDIUM

Recommendations:

1. Enforce allowlist of MIME types and/or file extensions before creating object URLs (both in PromptInputProvider.add and local add). Treat client-side checks as convenience only and duplicate validation server-side.
2. Explicitly reject or sanitize SVG uploads. Do not render user-provided SVG markup directly. If SVG support is required, sanitize the SVG (remove scripts, external references) on the server before serving, or rasterize it server-side.
3. Ensure maxFiles and maxFileSize are enforced consistently for both provider-backed and local attachment flows. PromptInputProvider.add currently does no size/count validation.
4. Normalize and validate filenames (e.g., strip control characters) before display. Note React escapes content by default, but normalizing avoids UI issues and accidental injection in other contexts.
5. When converting blob/object URLs to data URLs and later embedding content, avoid inserting raw data URLs into innerHTML. Prefer safe rendering methods ( with safe types) and server-side scanning for malware.
6. Apply a strict Content-Security-Policy (CSP) to mitigate the impact of any client-side render of malicious content and avoid using contexts that could execute SVG scripts (e.g., , , or innerHTML).
7. Add server-side validation and scanning for all uploaded files (MIME type, size limits, virus scanning) before storing or serving them to other users.

---

💡 Recommendations

View 3 recommendation(s)
1. Upgrade/patch vulnerable packages: replace xlsx@0.18.5 with a patched xlsx release and update ai to >= 5.0.52 (fix for GHSA-rwvc-j5jr-mgvh).
2. Sanitize and schema-validate AI-produced TipTap JSON before persisting ( PolicyDetails.tsx ): run markdownToTipTapJSON output through a strict allowlist Zod schema and a sanitizer (e.g., validateAndFixTipTapContent) and reject or normalize unexpected marks/nodes before calling updatePolicy.
3. Harden server-side input handling in apps/app/src/app/api/policies/[policyId]/chat/route.ts: validate/canonicalize policyId (e.g., UUID pattern), enforce authorization that the session may access/modify that policy, and validate message payload shape and size before DB queries or model conversion.

---

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

[claudfuen]

🎉 This PR is included in version 1.67.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀