Figma-to-Reactor: agent-driven design translation with CLI watch + Figma plugin

[karkarl]

Figma-to-Reactor Design Translation

End-to-end tooling for translating Figma designs (built with the Windows UI Kit) into Reactor C# code via AI agent workflows.

Architecture

Figma Design → Figma MCP (get_figma_data) → AI Agent
                                                ↓
                              Agent reads skills (figma.md + design.md)
                              and maps design elements → Reactor code
                                                ↓
                              Agent writes Program.cs → dotnet watch → app updates
                                                ↓
                              mur figma watch polls for changes → agent re-syncs

What's included

Spec

• docs/specs/033-figma-to-reactor.md — Full design spec covering architecture, layout IR, control mapping, token resolution, code generation, preview loop, validation model, and fidelity levels.

Skills

• skills/figma.md — Agent skill with Figma → Reactor translation rules: layout containers, WinUI control mapping (40+ controls), Theme token resolution, typography, corner radii, and two sync modes (one-shot URL paste + watch-based continuous sync).
• skills/design.md — Expanded with AppTheme.Register() guidance, corner radius resources, and theme-aware resource patterns.
• skills/design-docs/theme-aware-resources.md — Custom token registration via AppTheme.Register().

CLI: mur figma watch

• src/Reactor.Cli/Figma/ — Polling-based live sync. Watches a Figma file's lastModified timestamp via the REST API and emits JSON events to stdout when the design changes. The agent reads these events and re-fetches via the Figma MCP server — no bridge, no WebSocket, no open ports.
• FigmaApiKeyResolver — Auto-discovers the Figma API key from FIGMA_API_KEY env var, ~/.copilot/mcp-config.json, or .vscode/mcp.json.
• FigmaClient — Lightweight REST client with clear error messages for 429 rate limits vs 403 auth failures, plus retry+backoff.

Figma Plugin

• tools/figma-plugin/ — Figma plugin (reactor-figma-sync) with compact native-density UI:
  • Frame detection — auto-selects and populates project name from frame name.
  • New / Existing toggle — switch for scaffolding vs re-generation.
  • Generate — copies copilot -p prompt with skill references, Figma URL, and mur figma watch baked in. Auto-switches to existing mode after first generate.
  • Re-generate (existing mode) — diffs Figma frame against current Program.cs, applies targeted changes only.
  • Run — copies dotnet watch run command (existing project mode only).
  • Status indicators — pulsing green dot on Generate, solid green on Run.

Security model

• No localhost servers or open ports — removed the original FigmaBridge WebSocket relay.
• Plugin manifest: allowedDomains: ["none"] — no network from Figma sandbox.
• CLI auth reuses the Figma API key already configured for the Figma MCP server.

Depends on

• Spec 024 (AI Agent Devtools)
• Spec 015 (Styling Design)

[codemonkeychris]

Security review notes for the Figma bridge/plugin changes:

The Figma plugin is reasonably constrained in terms of Figma API permissions, but the local bridge substantially expands the trust boundary. I would recommend addressing the items below before merging, because the current design exposes selected Figma design data and local file/process operations through unauthenticated localhost endpoints.

Main recommended actions:

1. Require authentication for both bridge surfaces

   • Why: http://localhost:9228/mcp and ws://localhost:9228/figma are currently unauthenticated. Any local process, and potentially browser-hosted code that can reach localhost, can read the current design tree/summary or impersonate the plugin.
   • Remediation: Generate a per-session random secret when FigmaBridge starts. Require it on the WebSocket connection and MCP requests, e.g. WebSocket query/subprotocol plus Authorization: Bearer <token> for MCP. Reject missing/invalid tokens and avoid long-lived/static secrets.

2. Remove wildcard CORS on the local bridge

   • Why: Access-Control-Allow-Origin: * makes the MCP endpoint browser-readable if a web page can reach localhost. That turns the bridge into a data exfiltration path for Figma frame contents.
   • Remediation: Do not enable CORS for MCP by default. If browser access is needed, restrict to explicit trusted origins and require the auth token regardless of origin. Treat origin checks as defense-in-depth, not authentication.

3. Authenticate and validate the WebSocket producer

   • Why: A fake local client can connect to /figma, set figmaConnected, send fake design trees, set output directories, trigger project creation/generation, or launch watch processes.
   • Remediation: Require the same per-session token, validate message schemas, limit to one active plugin session, and reject commands not expected from the plugin.

4. Treat Figma content as untrusted input to the agent/codegen path

   • Why: Node names and text content are user-controlled and are included in prompts that are launched with Copilot CLI/autopilot and broad tool access. A malicious or shared Figma file could contain prompt-injection text that attempts to read/write local files or alter generated code. The generated Program.cs may then be run locally.
   • Remediation: Clearly delimit design content as untrusted data, add prompt-injection resistant instructions, remove or narrow --allow-all-tools, and require human confirmation before writing/running generated code. Prefer generating a patch for review rather than immediately running the app.

5. Avoid HTML injection in the plugin UI

   • Why: The UI logger builds rows with innerHTML using bridge-provided message text. Bridge messages can include Figma-derived strings such as frame names and paths. This can inject markup/script into the plugin iframe.
   • Remediation: Build DOM nodes and assign dynamic values via textContent instead of interpolating into innerHTML. Keep static SVG/icon markup separate from untrusted text.

6. Constrain local file writes and process launch behavior

   • Why: set-output, create-project, generate, browse-output, and launch-watch can create/modify files or start processes based on WebSocket messages. Without authentication and path validation, this is too much local authority for an open localhost service.
   • Remediation: Restrict output paths to an allowlisted workspace/repo subtree, sanitize project names to safe path/identifier characters, require confirmation for launching PowerShell/dotnet watch, and log command/target path decisions without logging design contents.

7. Add resource limits and safer defaults

   • Why: Large design trees, repeated launches, multiple connections, and long waits can DoS the bridge or spam local processes.
   • Remediation: Add max WebSocket/message/request body sizes, rate-limit generate/launch commands, bound figma_watch timeouts, use cancellation tokens, and close stale connections.

8. Document the security/privacy model in the spec

   • Why: The draft spec describes the architecture but not the local trust boundary or data handling. Users need to know that selected Figma text/layout data is copied out of Figma into a local MCP bridge and may be sent to an AI/codegen workflow.
   • Remediation: Add a security section covering data collected, retention lifetime (latestSync in memory), local endpoints, authentication, CORS/origin expectations, prompt-injection risk, and user approval points.

Overall: the concept is workable, but it needs an explicit local-bridge security boundary. The key fix is to make the bridge a capability-bearing session (random token + restricted origins + scoped commands), and to treat design content as untrusted data before it reaches any agent or executable code path.

[codemonkeychris]

See the security review comments... some of this may be bogus (might be limitations on how secure we can be, Figma may force us to be more open than we would want), but please add a security review to your spec, and harden as much as you can within the bounds of what Figma allows.

[karkarl]

See the security review comments... some of this may be bogus (might be limitations on how secure we can be, Figma may force us to be more open than we would want), but please add a security review to your spec, and harden as much as you can within the bounds of what Figma allows.

Re-architected the plugin. Got rid of the bridge architecture and am now exclusively relying on Figma's get_figma_data for live sync, so that should self resolve most of the security issues brought up by the agent. Let's see what the agent's security review is now.

[karkarl]

🔒 Security Threat Model — STRIDE Analysis

Scope: PR #178 new features (CLI mur figma watch, FigmaApiKeyResolver, FigmaClient, Figma plugin, figma.md skill)
Methodology: STRIDE per trust boundary, filtered through the project's threatmodel.md discipline

---

System Diagram

┌─────────────────────────────────────────────────────────────────┐
│ Developer Machine (single user, same principal)                 │
│                                                                 │
│  ┌──────────────┐     ┌──────────────────┐     ┌─────────────┐ │
│  │ Figma Plugin  │     │  mur figma watch │     │ dotnet watch│ │
│  │ (Figma iframe)│     │  (CLI process)   │     │ (app host)  │ │
│  │ sandbox       │     │                  │     │             │ │
│  └──────┬───────┘     └────────┬─────────┘     └─────────────┘ │
│         │ clipboard            │ HTTPS                          │
│         ▼                      ▼                                │
│  ┌─────────────┐     ┌──────────────────┐                      │
│  │  Terminal    │     │ Figma REST API   │◄── HTTPS ──┐         │
│  │ (copilot -p) │     │ (api.figma.com)  │            │         │
│  └─────────────┘     └──────────────────┘            │         │
│                                                       │         │
│  ┌──────────────────────────────────────┐             │         │
│  │ Config files (read-only)             │             │         │
│  │  ~/.copilot/mcp-config.json          │─── API key ─┘         │
│  │  .vscode/mcp.json                    │                       │
│  │  $FIGMA_API_KEY env var              │                       │
│  └──────────────────────────────────────┘                       │
└─────────────────────────────────────────────────────────────────┘

Trust Boundaries

#	Boundary	Components
TB-1	Network (HTTPS)	FigmaClient → api.figma.com
TB-2	User-content (Figma design data)	Figma frame names, text, node IDs → CLI output / generated code
TB-3	User-content (config files)	mcp-config.json / .vscode/mcp.json → API key extraction
TB-4	Process boundary (clipboard)	Plugin UI → system clipboard → terminal shell
TB-5	Figma plugin sandbox	Plugin sandbox (code.ts) ↔ UI iframe (ui.html) via postMessage

---

Findings

#	Title	Boundary	Severity	Category
F-1	Sanitize Figma text content in LLM-generated code	TB-2 (user-content)	🟠 Medium	Security
F-2	Strip ANSI control characters from frame names in stderr output	TB-2 (user-content)	🟡 Low	Reliability

F-1: LLM code injection via Figma text content (🟠 Medium)

The agent uses Figma design data to generate C# source code. A malicious Figma collaborator could craft text content (e.g., a text layer containing "); Process.Start("calc");) that the LLM might embed verbatim in generated Program.cs.

Mitigations already in place:

1. Developer reviews generated code before running
2. dotnet watch compiles and runs under the developer's own principal
3. The skill instructs the agent to emit TODO placeholders for unknowns, not arbitrary strings

DREAD: Damage 3, Reproducibility 2, Exploitability 2, Affected 2, Discoverability 2 = 11/25

Recommend: Add a rule to figma.md reminding agents to escape string literals from Figma text nodes (escape quotes, strip control characters) before embedding in C# code.

F-2: ANSI escape injection in stderr (🟡 Low)

Figma frame names flow into Console.Error.WriteLine without control character stripping. A Figma file name with ANSI escape sequences could confuse terminal rendering. The machine-readable stdout channel is safe (serialized via System.Text.Json).

DREAD: Damage 1, Reproducibility 3, Exploitability 1, Affected 1, Discoverability 1 = 7/25

Recommend: Optionally strip non-printable characters from FileName before stderr output. Low priority.

---

STRIDE Pass by Boundary (No Findings)

TB-1: Network — FigmaClient → api.figma.com

• Spoofing: TLS to api.figma.com with hardcoded https:// BaseAddress. Standard .NET cert validation. ✅
• Tampering: JSON responses parsed via JsonDocument (safe). name/lastModified/version treated as display strings, never executed. ✅
• Info Disclosure: API key sent as X-Figma-Token over HTTPS. Key is never logged. ✅
• DoS: Rate limiting (429) is self-inflicted by polling. Retry+backoff mitigations in place. → Reliability, not security.
• Elevation: fileKey interpolated into URL path is regex-validated (alphanumeric only). Figma validates server-side. ✅

TB-3: Config files → API key extraction

• Spoofing: Same-user config files. Attacker with user authority can already call the Figma API directly. ✅
• Tampering: Repo .vscode/mcp.json could supply a different key, but: env var and ~/.copilot/ take priority, and the API endpoint is hardcoded to api.figma.com. The key only grants read access to the attacker's own Figma files. ✅
• Info Disclosure: Resolver logs config file path (not key value) to stderr. Same-principal. ✅
• API key stored in plain text is the pre-existing Figma MCP server pattern — not introduced by this PR.

TB-4: Plugin clipboard → terminal shell

• Elevation: Plugin constructs shell commands from (1) project name — sanitized to [a-zA-Z0-9] from frame name, (2) csproj path — user-typed, (3) Figma URL — constructed from Figma IDs. The user pastes their own command. Self-injection is not attacker-controlled per four-question test. ✅
• Prompt wrapping uses '...' with replace(/'/g, "''") for PowerShell escaping. Figma IDs are constrained formats. ✅

TB-5: Figma plugin sandbox

• Spoofing: Only two message types handled (request-frame-info, set-file-url). URL validated via regex. ✅
• Elevation: allowedDomains: ["none"] — no network egress. enablePrivatePluginApi only grants figma.fileKey (file's own ID). ✅

---

Rejected Candidates

Candidate	Rejection reason
API key in plain text in mcp-config.json	Pre-existing Figma MCP config pattern. Same-user file. Not introduced by this PR.
Watch loop rate limiting (DoS)	Self-inflicted by developer's own polling. Reliability, not security.
Plugin copies commands to clipboard	User pastes their own command. Self-injection fails four-question test.
stderr leaks file paths and frame names	Same-principal display. Developer already knows their Figma file names.
Repo .vscode/mcp.json could supply attacker key	Env var takes priority. Key only accesses attacker's files. API endpoint hardcoded.
fileKey interpolated into API URL	Alphanumeric only (regex-validated). Server-side validation.

---

Recommendations

1. F-1 (Medium): Add a rule to skills/figma.md requiring agents to escape Figma text content before embedding as C# string literals
2. F-2 (Low): Optionally strip control chars from FileName in stderr output
3. Test coverage (non-security): FigmaClientTests only covers URL parsing — consider adding tests for HTTP error paths (429, 403) and config resolution

[codemonkeychris]

LGTM