fix(extension): harden booking URL handling

[dhairyashiil]

Summary

Hardens extension-controlled URLs by sanitizing booking links before preview/copy/insert, validating OAuth authorization and token endpoints, escaping rendered error text, and avoiding wildcard iframe postMessage replies.

Reviewer notes

• Booking URLs are now limited to Cal.com-owned hosts: cal.com, www.cal.com, cal.eu, and www.cal.eu.
• Please confirm whether the extension needs to support custom domains or self-hosted booking hosts. If yes, we should add an explicit allowlist/config path before merging.
• OAuth authorization must resolve to the expected Cal.com app authorize route, and token exchange must use the expected Cal.com API token route.

Validation

• bun --filter extension test -- lib/utils.test.ts
• bun --filter extension typecheck
• bun --filter extension build
• git diff --check HEAD~1..HEAD

[vercel]

@dhairyashiil is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[devin-ai-integration]

Devin Review found 2 potential issues.

[cubic-dev-ai]

4 issues found across 7 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/extension/lib/utils.ts">

<violation number="1" location="apps/extension/lib/utils.ts:12">
P2: The hardcoded `SAFE_BOOKING_HOSTS` allowlist will silently reject booking URLs on custom domains (Cal.com supports custom booking domains like `booking.mycompany.com`). When a user has a custom domain configured, the API-returned `bookingUrl` will fail the host check and the function will fall back to `https://cal.com/username/slug`, which may not be the correct booking page for that user. Consider adding an explicit configuration path or documenting this as a known limitation before merging.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 6 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[volnei]

Left a comment

[volnei]

This validator rejects the endpoints the companion app actually uses. The iframe sends https://app.cal.com/api/auth/oauth/token for exchange (apps/mobile/services/oauthService.ts:352, calcomBaseUrl comes from getCalAppUrl which returns app.cal.com/app.cal.eu) and https://app.cal.com/api/auth/oauth/refreshToken for refresh (line 547), both routed through handleTokenExchange. Suggest validating against an explicit set of known-good full endpoints (app.cal.com and app.cal.eu origins with the /api/auth/oauth/token and /api/auth/oauth/refreshToken paths), and adding tests that use these real URLs so the contract cannot drift again. As it stands, extension OAuth login and refresh will fail for everyone.