Example scope & report

# Cal.com: booking portal access review

Review the customer application that exposes team bookings and meeting details

[← All services](/services)

Public reference: Cal.com. Independent example based on public documentation. Not commissioned by or affiliated with Cal.com.

[Download all 7 reports (PDF) ↓](/examples/upserto-example-reports.pdf)[Download Markdown ↓](/examples/security-review.md)

## Decision brief

Recommended next decision

| Question | Recommendation |
| --- | --- |
| Decision | Check booking ownership at every customer-portal access path. |
| Why it matters | A valid session or provider token does not establish authority over a requested booking. |
| Acceptance | Allowed and denied fixtures cover the agreed routes and produce attributable, redacted evidence. |
| Scope boundary | Customer-owned portal and its Cal.com adapter; authorization is required before testing. |

## The proposed engagement

Proposed brief: an agency uses Cal.com and exposes booking details through its own client portal. Staff should see only the customers and teams they are assigned to. Upserto would review the portal’s session, local customer mapping and server-side Cal.com calls, then test an agreed access matrix with seeded accounts. This proposal does not allege a vulnerability in Cal.com.

Inputs required. Portal code; local role model; Cal.com app/scopes; seeded bookings and two isolated customer identities.

## System boundary and assumptions

Cal.com documents API v2 roles, permissions and OAuth scopes. Its booking API can return attendee and meeting information, so the portal must define which fields each local role may receive. The proposed review covers the customer-owned proxy and interface, not Cal.com infrastructure. Testing would require written targets, permitted identities, a time window and stop conditions. No service was scanned or exploited for this example.

## How Upserto would approach it

Map local identities to Cal.com users, teams and bookings before testing. Check authorization at the server request boundary, not only in visible navigation. Use known seeded booking identifiers to test cross-customer requests without enumeration. Inspect cache keys, exported links and redacted denied-event logs. Stop immediately if unexpected real data appears.

## What the team would receive

- An access matrix and source-linked review items for the customer portal.

- Minimal redacted reproductions for any verified in-scope issue.

- A remediation proposal and retest checklist covering permitted and denied behavior.

Authorize the portal caller before returning booking dataThe customer portal must enforce its own object and field access rules. An upstream Cal.com credential is not the portal user’s authorization.Dashed frames: trust boundaries · Deny path returns no booking fields

Read the diagram- Bind caller, customer or team assignment and booking object before returning upstream data.

- A denied cross-customer request stops at the portal authorization gate.

- Return only role-approved fields; keep tokens and meeting details out of routine logs.

## Starting point and proposed change

Items to inspect in the customer integration, the proposed control and the evidence needed for acceptance.

Design comparison

| Control | Inspect first | Proposed change | Acceptance evidence |
| --- | --- | --- | --- |
| Object access | Review reliance on shared upstream credentials. | Portal customer/team authorization before returning data. | Seeded cross-customer read/action is denied. |
| Field access | Review complete upstream responses sent to the browser. | Role-specific response fields and scoped upstream access. | Restricted and revoked roles receive no disallowed field. |
| Audit trail | Review generic errors or full-payload logging. | Redacted, attributable access decision. | Operator can investigate denial without attendee/meeting content. |

## Decisions and approval owners

Decisions to agree before implementation

| Decision | Proposed default | Approval owner |
| --- | --- | --- |
| Test authority | Agree routes, identities, tenant fixtures and the permitted environment in writing. | Application + security owners |
| Access policy | Define tenant, support and administrator permissions before interpreting an access result. | Product + security owners |

## Review questions and implementation risks

P1 Resolve before releasing the affected workflow, or record an explicit acceptance decision. P2 Assign an owner and an agreed follow-up milestone; do not leave the item unowned.

### SEC-01 · P1 · Does the portal bind a booking to the caller’s customer?

If the proxy accepts a booking UID and relies only on a shared upstream credential, its local customer boundary may be missing. That possibility must be verified in the portal code and approved fixtures.

Proposed approach. Scope each lookup and action to the caller’s current assignment before the upstream response is returned. Test status, details and any mutation separately.

### SEC-02 · P1 · Are upstream data and scopes broader than the UI needs?

Booking responses may contain attendee or meeting fields that a restricted portal role should not receive. Hiding a field visually does not remove it from the response.

Proposed approach. Define response DTOs per role and review the upstream identity/scopes. Confirm access after membership or assignment changes, including cached responses.

### SEC-03 · P2 · Can denied requests be investigated without leaking data?

A generic error is insufficient for support, while full booking payloads in logs can expose personal or meeting information.

Proposed approach. Record a correlation ID, actor, scoped object reference and decision reason. Exclude attendee details, tokens and meeting URLs from routine logs.

## Example technical output

Proposed access checks, using seeded identities

```text
caller: portal_user_customer_B
requested_booking: seeded_customer_A_booking
local_scope_check: required_before_upstream_response
allowed_result: deny_without_booking_fields
control_case: customer_A_owner_can_read_allowed_fields
log: correlation + actor + decision; no meeting URL
execution_result: TO_VERIFY
```

## Delivery plan and ownership

Proposed action plan

| Priority | Review item | Accountable role | Acceptance gate |
| --- | --- | --- | --- |
| P1 | SEC-01 | Portal backend owner | A cross-customer fixture returns no booking fields or meeting URL; the authorized owner still works. |
| P1 | SEC-02 | Backend + security owner | Restricted roles receive only approved fields; revoked assignment cannot read a cached response. |
| P2 | SEC-03 | Security operations | Denied decisions are attributable with no sensitive booking content in logs. |

## Acceptance checks

Run these checks before accepting the proposed changes.

Acceptance checks

| Scenario | Required evidence / expected behavior | Status |
| --- | --- | --- |
| Customer B requests customer A seeded booking | No attendee fields, meeting URL or action authority | To verify |
| Assigned owner requests the same booking | Approved fields and intended action remain available | To verify |
| Assignment is revoked after a cached read | Current authorization is enforced; stale cache does not disclose | To verify |
| Denied request is inspected in logs | Attributable decision without personal or meeting content | To verify |

## Rollout and recovery

Use an isolated test setup and approved identities first. Remediate verified issues in small changes, then retest both denied and legitimate flows. A rollback must not restore a missing access check; disable the affected portal action if needed while preserving the safer authorization boundary.

## Handover and limits

The report would separate verified issues, assumptions and untested paths, with affected versions and redacted evidence. A focused portal review is not a certificate that every Cal.com integration or application route is secure.

## Access and evidence handling

Controls for the agreed engagement

| Area | Required control |
| --- | --- |
| Test data | Use synthetic tenant identities and bookings; do not probe unrelated accounts. |
| Secrets | Keep provider credentials server-side and out of screenshots, issue text and report attachments. |
| Evidence | Deliver minimal redacted request/response pairs through the agreed restricted channel. |

## Public documentation used

The sources below establish product capabilities and API contracts. The implementation choices above are Upserto’s proposed approach for a customer integration.

- [Cal.com: API v2 Access Control ↗](https://cal.com/docs/api-reference/v2/access-control)Documents role, membership, PBAC and OAuth scope boundaries.

- [Cal.com: Get a booking ↗](https://cal.com/docs/api-reference/v2/bookings/get-a-booking)Documents booking identifiers, authentication and returned attendee/meeting fields.

Discuss the same kind of work for your system, with an agreed scope and acceptance criteria.

[Explore Cybersecurity and risk review ↗](/services/cybersecurity-review)[Discuss a similar scope ↗](/contact)

Contact: [hello@upserto.com](mailto:hello@upserto.com)