[comp] Production Deploy

[github-actions]

This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app (staging)	Ready	Preview	Comment	Oct 31, 2025 5:26pm
portal (staging)	Building			Oct 31, 2025 5:26pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🟡 Risk Level: MEDIUM

No OSV CVEs found and no hardcoded credentials observed. Code shows input-validation risks: path/URL manipulation (revalidatePath, href concat) and potential email header injection.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 4 file(s) with issues

🟡 apps/app/src/actions/policies/publish-all.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Role check uses includes('owner') — substring auth bypass	MEDIUM
2	Role filter uses contains(Role.employee) — substring match risk	MEDIUM
3	No strict validation of organizationId format	MEDIUM
4	User input used in revalidatePath URL — path manipulation risk	MEDIUM
5	Verbose error logging includes stacks and IDs — sensitive data leak	MEDIUM

Recommendations:

1. Use strict role checks. If role is a single enum/string, compare equality (e.g., member.role === Role.owner). If roles are stored as an array, check membership with exact matches (e.g., Array.includes(Role.owner) where Role.owner is the canonical enum). Avoid substring checks like .includes('owner') on freeform strings.
2. Avoid substring filters in DB queries. Replace role: { contains: Role.employee } with an exact match or a proper relation/array containment operator depending on your schema. E.g., role: Role.employee or role: { equals: Role.employee } or use a normalized many-to-many members->roles table.
3. Validate organizationId with a stricter schema (e.g., z.string().uuid()) or a custom refinement. Reject or canonicalize malformed IDs server-side before using them in DB queries or URL paths.
4. Sanitize/encode path segments before calling revalidatePath. Treat parsedInput.organizationId as untrusted: validate format and then build the path using a safe join/encoding method (or fail if invalid) to prevent path manipulation.
5. Reduce sensitive logging in production. Avoid printing full error stacks and internal identifiers (userId, memberId, organizationId) to console/error logs. Use structured logging with redaction or log levels; only include minimal context in production and preserve full details in secure dev/error-reporting tooling (with access controls).
6. Handle per-policy failures more gracefully to limit blast radius: don't re-throw on single-policy update failure unless you must. Collect failed updates and return partial success with a list of failures, or implement transactional semantics if atomicity is required.
7. Add unit/integration tests around role parsing and membership/permission checks, and add validation tests for organizationId path handling to prevent regressions.

🟡 apps/app/src/jobs/tasks/email/publish-all-policies-email.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing input validation for payload (email, userName, organizationId)	MEDIUM
2	Logging sensitive PII (email) in plaintext logs	MEDIUM
3	Rethrowing raw errors may leak internal details	MEDIUM

Recommendations:

1. Validate and sanitize the task payload before use. Enforce a schema (e.g., Zod/Joi) for AllPolicyEmailPayload and validate fields: well-formed email (use a proper validator), safe userName (length/char restrictions), and organizationId format (UUID/DB id constraints). Reject or normalize invalid payloads before calling sendAllPolicyNotificationEmail.
2. Avoid logging raw PII. Replace email in logs with a masked value (e.g., a@*****.com) or a one-way hash, or log only an internal identifier (organizationId, user id) and correlate externally in a secure store.
3. Do not propagate raw internal error messages to external callers. Wrap errors in a sanitized application-level error for outside surfaces and log full error details only to secure/internal logs/observability with restricted access. Consider capturing stack traces in an internal monitoring system rather than rethrowing raw errors that may surface sensitive implementation details.
4. Add server-side checks before sending (verify recipient address exists/is allowed, rate limiting at the send layer), and ensure retry/backoff policies and observability for failed deliveries.
5. Enforce input validation at the enqueue point as well as at task runtime to prevent malicious or malformed payloads from being processed.

🟡 packages/email/emails/all-policy-notification.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated user props rendered directly (userName,email,organizationName)	MEDIUM
2	Unsanitized organizationId concatenated into href without encoding	MEDIUM
3	External webfont resources may leak opens or enable tracking	MEDIUM

Recommendations:

1. Sanitize and validate all user-supplied props before rendering server-side. Even though React escapes text nodes, validate format/length and strip unexpected markup/characters for values that appear in emails (userName, email, organizationName).
2. Use encodeURIComponent(organizationId) (or a stricter whitelist of allowed characters) when building URLs: ${base}/${encodeURIComponent(organizationId)}. Also validate that organizationId cannot start with protocol characters or contain characters that could change the intended path.
3. Validate NEXT_PUBLIC_PORTAL_URL at build/runtime: ensure it is an expected origin (https-only) and normalize trailing slash handling before concatenation.
4. Avoid remote webfont hosts for email if you want to prevent remote tracking. Host fonts/resources locally or remove remote font references. If remote fonts are required, use a privacy-preserving CDN you control and be aware that loading them can register opens.
5. Treat any user-supplied fields used in URLs or attributes conservatively: apply encoding and strict validation (whitelists) rather than relying solely on output escaping.

🟡 packages/email/lib/all-policy-notification.ts (MEDIUM Risk)

#	Issue	Risk Level
1	No validation of recipient email	MEDIUM
2	Possible email header injection via 'to' field	MEDIUM
3	No format/length checks for userName, organizationName, organizationId	MEDIUM
4	Error logs may expose sensitive internal data	MEDIUM

Recommendations:

1. Validate and canonicalize the recipient email before calling sendEmail. Use a robust email validation library (RFC5322 or a well-maintained package) and normalize the address (lowercase the domain, trim whitespace). Reject or return an error for invalid addresses.
2. Defend against header injection: explicitly reject or strip CRLF/newline characters from any email header fields (to, cc, replyTo, from) before passing them to the email SDK. For example, validate that 'to' matches a validated single address or a list of addresses without CRLF/controls.
3. Enforce format and length checks for userName, organizationName, and organizationId. Apply reasonable max lengths and canonical validation (e.g., organizationId should be an identifier token — validate via regex). For values used in URLs (organizationId), apply encodeURIComponent or validate against an allowlist pattern to avoid malformed links.
4. Avoid logging raw error objects that may contain sensitive data. Redact or sanitize error messages before logging, or log only annotated error identifiers and limited context. Use structured logging with redaction policies for any PII or secrets.
5. Consider server-side sanitation/encoding for values inserted into emails. While JSX escapes values by default (see reasoning), ensure any future use of dangerouslySetInnerHTML or raw HTML/template injection is avoided or sanitized.
6. Optionally, rely on the email provider/SDK validation where appropriate but do not treat it as the sole defense. Perform input validation on your side before delegation to third-party SDKs.

---

💡 Recommendations

View 3 recommendation(s)

1. Validate and encode organizationId before using in paths or revalidation calls (e.g., enforce UUID/alist regex, then use encodeURIComponent when building revalidatePath or href). Fail fast on invalid IDs rather than concatenating raw input into URLs.
2. Defend email header fields against injection: validate recipient emails with a robust validator, strip/reject any CRLF/newline characters from 'to' and other header fields, and normalize/truncate fields to safe lengths before calling sendEmail.
3. Replace substring role checks with exact matches: avoid .includes('owner') on freeform role strings. Use canonical enums/values (e.g., member.role === Role.owner or role: { equals: Role.employee }) or a normalized membership relation so authorization decisions cannot be bypassed by substring matches.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Oct 31, 2025

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[claudfuen]

🎉 This PR is included in version 1.56.6 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀