theme-saas-workspace

name	theme-saas_workspace
description	Multi-tenant SaaS workspace palette: variants, pages, entities, and flows for building a varied team-collaboration app. Use when theme_preset is saas_workspace.

SaaS workspace theme

Domain

Multi-tenant B2B apps where data is scoped to an organization/workspace and shared with invited members. The tenancy boundary (org → workspace → resource), member roles, and per-seat billing are exactly where access and logic exploits live — this is the natural home for cross-tenant data bleed.

Application variants — pick ONE per lab

Honor any hint in theme_free_text / custom_prompt; otherwise pick one.

• Project / task tracker — projects, tasks, boards, assignees, comments.
• Docs / wiki workspace — spaces, pages, nested docs, sharing, comments.
• Team chat — channels, messages, threads, DMs, mentions.
• CRM — accounts, contacts, deals/pipeline, activities, notes.
• Helpdesk-lite — inboxes, conversations, assignment, internal notes.

Roles — choose the set that fits the variant

• user (member) — work inside their own org's workspaces and resources.
• service — integrations / webhooks / scheduled jobs where relevant.
• admin (org owner) — manage members, roles, billing, all org resources.

Most exploits run as member.

Candidate pages — select a coherent subset

Size the subset to endpoint_count. Candidates: workspace switcher, dashboard, project/space list, board or document view, resource detail (task/page/deal/ conversation), create resource, comments thread, members & invites, role management, billing & plan, settings, notifications, search, profile, admin org settings.

Candidate entities (seed tables) — select what the variant needs

• users — id, email, password_hash
• orgs — id, name, plan, seats, owner_id
• memberships — id, org_id, user_id, role (owner/admin/member), status
• workspaces / projects / spaces — id, org_id, name, visibility
• resources — id, workspace_id, kind, title, body, created_by, assignee_id
• comments — id, resource_id, author_id, body, created_at
• invites — id, org_id, email, role, token, expires_at, accepted_at
• api_tokens — id, org_id, name, scope, last_used_at

Variant-specific resource flavor (CRM: accounts/contacts/deals; chat: channels/messages; docs: pages with parent_id; helpdesk: conversations/messages).

Seed ≥2 orgs, each with several members and resources, so cross-tenant access is testable. Make IDs guessable/sequential where it sets up the exploit.

Candidate user flows — select the ones matching chosen pages/features

1. Switch workspace → open a project/space → view its resources.
2. Create a resource (task/page/deal/conversation) → assign it → comment on it.
3. Invite a teammate by email → they accept → they appear as a member.
4. Change a member's role (owner/admin) → their permissions update.
5. Move/share a resource between workspaces in the same org.
6. (billing) View the plan & seats → upgrade tier → seat count updates.
7. (admin) Open org settings → manage members, tokens, and billing.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• workspaces / projects — GET /api/workspaces, GET /api/projects/{id}, POST /api/projects
• resources — GET /api/resources/{id}, POST /api/projects/{id}/resources, PATCH /api/resources/{id}, GET /api/projects/{id}/resources
• comments — GET/POST /api/resources/{id}/comments
• members / invites — GET /api/orgs/{id}/members, POST /api/orgs/{id}/invites, POST /api/invites/{token}/accept, POST /api/orgs/{id}/members/{uid}/role
• billing — GET /api/orgs/{id}/billing, POST /api/orgs/{id}/upgrade
• tokens — GET/POST /api/orgs/{id}/tokens
• admin — GET /api/admin/orgs, POST /api/admin/orgs/{id}/...

Where vulnerabilities fit naturally

• idor (tenant bleed) → GET /api/projects/{id}, /api/resources/{id}, /api/orgs/{id}/members — read or edit another org's data by guessing IDs. This is the signature flaw of the domain.
• privilege_escalation → member→admin/owner via role tamper, accepting an invite to elevate, or POST .../members/{uid}/role on yourself.
• business_logic → exceed paid seats by inviting past the limit, act on a workspace after losing access, reuse an expired/used invite token.
• auth_bypass → use an org-scoped API token against a different org; reach admin org settings without owner rights.
• idor/business_logic → move a resource into an org you don't belong to.

Diversity guidance

Pick ONE variant and a coherent subset — a CRM and a team-chat app diverge sharply in resources and pages. Size to endpoint_count; let theme_free_text / custom_prompt bias the variant and naming. Vary org sizes, role models, and plan tiers so two SaaS labs feel like different products. Pairs naturally with the existing tenant-bleed spec.