Our approach to security at speed

On the Figma security team, our goal is to help Figmates ship new products and features as securely as possible—all without slowing them down. We wanted to share our operating model, which prioritizes transparency, decentralized and reusable solutions, and earning trust over mandating processes.

Systematically assessing risk

Last year, the FigJam team built rich previews for links. A user can paste a link into FigJam and instead of only seeing link text like https://figma.com they see a tile that includes the icon, description, and other metadata from the linked site.

We take an integrated approach to make sure any new features like rich preview links are secure. That includes periodically reviewing upcoming new features and workflows to identify potential security risks and reaching out to the appropriate teams to better understand and help them secure their projects. We also host security team office hours three times a week to answer questions and discuss upcoming product launches. Before office hours, we ask Figmates to answer a three-question survey called “ThreatJam,” which lives in a FigJam file:

The questions prompt Figma’s product teams to share information with the security team so we can assess potential risks, from the possibility of compromised vendor components to misconfigured cloud resources. For example, the team that built rich preview links reached out to us for advice on how to fetch the link metadata to include in previews. After seeing their responses to the survey and discussing live at office hours, we identified the potential for malicious users to:

• Enter internal Figma server links to leak internal resources (a vulnerability known as server-side request forgery or SSRF)
• Use Figma’s resources to send requests to a linked site taking it offline (a.k.a. denial of service or DoS)
• Link to sites with malicious HTML that deface or run on FigJam

To prevent these attacks, we suggested isolating the scraping and parsing code that handles user input in a cloud function. The cloud function runs code in a separate virtual computer on a separate virtual network. This isolates it from the rest of Figma’s infrastructure and prevents SSRF attacks from having any impact. This capability is one of many security advantages of cloud-native infrastructure.

To limit our traffic to linked sites, we use the built-in cloud function rate limiting, save the scraped data for a limited time, and only allow requests to the standard HTTP and HTTPS ports. For malicious HTML we limit parsing to specific tags, and reuse existing work to secure plugins and widgets to safely embed the link metadata (previously discussed here and here). Following through on our recommendations, we provided links to code and documentation to help the team get started and review the code they wrote. Using cloud function features helped them quickly ship link previews while also addressing the potential attacks.

While we offer a set of customized recommendations to each team, we aim to decentralize decision making and create scalable solutions so that we’re not solving the same problem over and over again. This means that we focus on building libraries, frameworks, and mental models for other teams. Once we work with a team on a solution, oftentimes other teams will use it as a case study. For example, after we partnered with the FigJam team on link metadata fetching, other engineering teams have reused the pattern to implement similar functionality.

We also make office hours notes available to all Figmates, so that other teams can understand the thinking behind our guidance and get context on the work we do. Sharing information is key to creating a culture where security isn’t a blocker, but an enabler.

Defending against phishing and unintended information disclosures

In addition to identifying product risks, we’re also responsible for helping a growing number of Figmates secure their devices and data. Our security team is small, so we rely on technical controls that effectively counter known attacks. For example, to mitigate the risk of phishing, Figmates are only able to access internal sites with a password-less second factor, scoped only to work on the site they’re accessing. When someone joins Figma, we send them a hardware authenticator key and help them register biometric authenticators—like Apple’s Touch ID or Windows Hello—on their laptop and phone.

When they access an internal site, it issues a challenge, their authenticator prompts them to tap or touch their key or device to prove their identity, and the authenticator signs and returns a response for the site to validate. These FIDO2 / WebAuthn technologies augment our training with best-in-class phishing defenses, and are faster and more convenient than having Figmates remember and enter passwords and codes. Figmates have even made their own keychains to hold the hardware keys.

As a result, we can spend less time worrying about Figmate behavior and more time working on Figma itself.

Another example of this is our approach to document security. We anticipated that employees might inadvertently share internal documents with people outside the company or forget to lock down sharing permissions that could leak sensitive information. We’ve found that an automated detective control can provide a faster response time than manual intervention, so we wrote a bot to help scale this process. When a Figmate makes a document publicly available, they receive a Slack message confirming that they meant to make it public, along with directions on how to limit sharing.

What used to be a manual process that involved user training and individual outreach, has become a totally automated exercise that educates as it secures our document infrastructure.

Building for scale

Figma has doubled in size over the past year—and so has the security team. We're continuing to find ways to make it easier for new members of our team to get up to speed quickly, and free up time for them to focus on other priorities in the process.

Our team is comfortable writing code, so we can rely on services with APIs to reuse and combine our tools and data. Since Figma runs in a public cloud, we can plug in vendors that use the cloud APIs. And to minimize operational toil, we prefer serverless cloud functions for our internal security tools (like sending the Figma Security Bot notifications above), instead of processes that require us to manually review alerts.

Beyond the initiatives here, we also work on a range of other projects, including tracking and incorporating data into our team planning, managing our bug bounty program, running penetration tests, monitoring security incidents or near misses, and building static and dynamic analysis tools. Our approach will evolve and grow with Figma, keeping the platform secure as it scales. We’re always looking for new Figmates to work with, if you’re interested take a look at our open positions.