Plugin Sandboxing And API Security

What's being tested

The interviewer is testing whether you can design an untrusted-code boundary, not merely hide implementation details behind an API. You should be able to distinguish isolation, authorization, input validation, and resource control, then explain how they work together when a malicious plugin attempts to read or modify Figma data. Figma cares because plugins run third-party code alongside valuable design documents, so a software engineer must preserve usability without turning every API call into unrestricted access.

Core knowledge

• Threat modeling starts by identifying assets, principals, trust boundaries, and abuse cases: document contents, access tokens, user identity, collaboration data, plugin code, and Figma’s backend. Treat every plugin as potentially compromised, including one whose author account or dependency was hijacked.

• A sandbox limits what code can execute and access; it is not an authorization system. Browser mechanisms such as an iframe with a restrictive sandbox attribute, separate origins, Content-Security-Policy, and disabled network primitives reduce blast radius, but every exposed host API still needs independent authorization.

• Use capability-based security: expose narrowly scoped object capabilities rather than a universal document object or ambient credentials. A capability might permit reading selected nodes or creating an image, while omitting arbitrary filesystem, network, token, or cross-document access.

• The host/plugin boundary should use an explicit RPC protocol over postMessage or a similarly constrained channel. Validate message shape, protocol version, request identifier, operation, argument types, and payload size; reject unknown operations instead of silently ignoring them.

• Origin validation must check event.origin against an exact allowlist and, where applicable, verify event.source is the expected window. postMessage("*"), substring origin checks, and trusting a claimed origin inside the message enable spoofing or confused-deputy attacks.

• Prevent confused deputy behavior by making the host enforce the caller’s permissions, not by trusting plugin-supplied document IDs, user IDs, or scopes. A plugin should not cause the privileged host to perform an operation the user or plugin capability does not authorize.

• Data minimization reduces exfiltration impact: return only fields needed for an operation, avoid sending entire documents for a single property query, redact secrets, and distinguish read, write, export, and network permissions. Consent dialogs should describe durable capabilities concretely.

• Content Security Policy should use restrictive directives such as default-src 'none', narrowly scoped script-src, and explicit connect-src where network access is genuinely required. CSP is defense in depth; it does not make unsafe DOM insertion, eval, or unvalidated HTML safe by itself.

• Apply resource quotas at both the plugin and request level: CPU time, memory, message size, operation count, file/export size, and wall-clock duration. Use cancellation and backpressure so a plugin cannot freeze the editor through millions of synchronous host calls or oversized responses.

• Serialization boundaries require defensive parsing and safe reconstruction. Prefer structured clone or a schema validator over ad hoc JSON assumptions; reject prototype-bearing objects, recursive structures, unexpected numeric ranges, and values that could trigger prototype pollution or denial of service.

• Network access is a major exfiltration and SSRF boundary. If plugins can fetch URLs, mediate requests through a host service with destination policies, credential stripping, response-size limits, timeout controls, private-address blocking, and clear user consent; never forward editor cookies or bearer tokens automatically.

• Revocation and lifecycle matter after installation: bind capabilities to a plugin identity and document context, expire temporary grants, invalidate them on uninstall or logout, and terminate workers or frames on navigation. Permission changes must affect already-running plugin instances, not only future calls.

• Observability and failure handling should record plugin identity, operation name, decision, latency, quota violations, and error class without logging document contents or secrets. Fail closed on malformed requests, isolate crashes, and make retries safe through request IDs and idempotent mutations where possible.

Worked example

No titled interview prompt was supplied, so use this representative prompt: “Design a secure API for third-party Figma plugins.” In the first 30 seconds, clarify whether plugins need network access, whether they can access one document or many, whether the requirement is malicious-code isolation or mainly accidental misuse, and what latency and compatibility constraints exist. State the core assumption: plugin code is untrusted, while the editor host and authorization service are trusted but must defend against confused-deputy requests. Organize the answer around four pillars: isolated execution, a versioned capability-based RPC API, strict validation and authorization at the host boundary, and quotas plus monitoring for availability. Explicitly choose narrow capabilities over a broad document object, accepting more API design and compatibility work in exchange for a smaller blast radius and clearer permission review. Explain that postMessage origin checks alone are insufficient because a legitimate plugin origin can still issue unauthorized operations. Close by saying that, with more time, you would specify the permission model, threat-test the protocol with fuzzing, and review network mediation and revocation behavior.

A second angle

A different representative prompt is “A plugin can read document data but must not exfiltrate it; how would you design the boundary?” The framing shifts from general sandbox architecture to information-flow control and the limits of host enforcement. A capability system can restrict which data is returned, but once plaintext reaches plugin memory, a malicious plugin may encode it into an allowed network request or visible side effect. A strong answer therefore combines minimized data access with explicit network policy, user-visible consent, auditing, and a product decision about whether that plugin class should receive sensitive data at all. The key insight is that sandboxing cannot guarantee confidentiality after intentionally granting an untrusted program the secret.

Common pitfalls

Pitfall: Saying “run it in an iframe, so it is safe” confuses execution isolation with authorization and data confidentiality. Explain the browser boundary, then separately define capabilities, origin checks, validation, network policy, and quotas.

Pitfall: Listing security controls without clarifying the threat model makes the design sound generic. State whether the attacker is a malicious plugin, a compromised dependency, a malicious document, or an attacker controlling a plugin’s server; each changes the required boundary.

Pitfall: Focusing only on XSS or CSP misses operational failures such as stale permissions, oversized messages, denial of service, token leakage, and confused-deputy calls. Discuss lifecycle, revocation, failure modes, and observability after the initial launch.

Connections

The interviewer may pivot to OAuth scopes, zero-trust authorization, browser same-origin policy, postMessage protocol design, SSRF prevention, or secure supply-chain practices. They may also ask how capability revocation interacts with distributed services and offline plugin execution.

Further reading

• Capability-Based Security — Foundational discussion of object capabilities and authority confinement.

• Content Security Policy Level 3 — Formal browser policy model and directive semantics.

• Postel’s Law Is Wrong — Useful context for why strict protocol validation is safer than permissive parsing.