Learn about the security of Coda Packs, managing Packs for your workspace, and security best practices.

Coda has always been built for teams. So when we started developing Packs, we designed them for the largest enterprise organizations to use. And the immediate priority for enterprise organizations was security.

Instead of relying on the Pack maker to meet specific requirements for each of their Packs, we designed the Packs platform to abide by a strict protocol globally that would ensure organizations with the most strict security requirements could use Packs.

The purpose of this article is to overview the measures Coda has taken to secure Packs, including what Packs are able - and not able - to access, how to understand each Pack security page, and more.

Overview of Pack security

Designed with security from the ground up

Restricted network requests: We ensure Packs only share data with the website they say they do. Some of our most popular Packs are integrations — connections to external data sources. Pack makers must declare which domains their Pack connects to, which we publish to users of the Pack in each Pack’s security tab, found on the Pack listing page. Coda enforces that Packs can only ever connect to these declared domains.

Locked-down authentication: We never let developers touch users’ login details. For Packs that require user authorization credentials, Coda handles credentials on behalf of the Pack, stores them encrypted at rest, and applies them to outgoing requests such that neither Pack code, Pack makers, nor other users of a doc ever have access to them.

Rigorous evaluation: Packs run in a dedicated, secure server. We execute Packs in a secure sandbox environment that isolates Pack executions from Coda’s broader infrastructure and data from other executions of Packs. The infrastructure receives an annual professional penetration test and receives constant evaluation via Coda’s bug bounty program.

Just what you share, and no more: When a Pack is executed, it only receives the data that the user explicitly provided — e.g. formula parameters — and no other content from your doc.

Covered by everything that already makes Coda secure: SOC 2 Compliant, data encryption, data access controls, and more all come standard with Coda. Learn more.

Data flow through Packs

Packs integrate data into Coda docs in two ways:

Pulling data in, such as a dashboard embedded into a project management hub.
1. Think of this as ‘read-access.’ You can see but you can’t touch. Ideal for status updates, presentations, and centralized working hubs. Some common examples are embedded Figma files or YouTube videos.
Pushing data out, such as a button that pushes updates to a Jira board.
1. Think of this as ‘write-access.’ You can act on the data — update status, send a message to Slack, email notes via Gmail, or create a new GCal event.

Note that these integrations are on a per-doc basis, not across all docs connected to a user or an entire workspace. When you enable a Pack for one doc, this does not enable that Pack for all docs in your workspace or all docs that you’ve created. This means each doc can have a different Pack setup depending on your specific needs.

When you sign in to an account to install a pack you can set up permissions for who can access data and who can take actions with the account from the Coda doc.

Pulling in third-party app data into your Coda doc

Packs have granular sharing settings to protect your privacy. When connecting a Pack to your Coda doc, you have two sharing options:

You and anyone this doc is shared with ー Setting this access for an account will set up a shared account. Users will be able to create sync tables and view data, use formulas and column formats.

You might choose this option for personal docs or if the information should be viewed by everyone in the doc. For example, a shared team Google Calendar or a Mode Dashboard that tracks your team’s OKRs.
Nobody ー this limits the data from being pulled into the doc, so it can only be actioned on by you. Setting this access for an account will set up a private account. No Sync tables can set up for this account and Coda will not pull in data from the account to use formulas or column formats.

If you select Nobody, only you can take actions on this account. For example, with the Gmail pack, only you can send an email or create a draft. You might choose this to control permissions on Gmail pack when you don’t want anyone to pull data from your Gmail, but you do want to use the button to send emails from your account.

Pushing Coda doc data to a third-party app

Packs can pull data in and can also push data out. Depending on how the Pack account is connected, you have three options to choose from to ensure your data is always secure:

Only you ー you are the only one who can push out any actions or data from the Coda doc to the third-party app, other users will have to sign in with their own accounts to take actions with the pack. While users can access the pack tables, they will not be able to take actions with buttons.

For example, you may have the Slack Pack enabled for your doc and you’ll be the only one who can push messages from your doc to Slack. Each user can set up their own Slack Pack so they can all push out messages from their own account.
Anyone this doc is shared with ー any user who can access the doc can push out data. Setting this access for an account will set up a shared account and any user may take actions on behalf of this account.

If we continue the Slack example, this means that everyone in the doc can push out messages from your doc to Slack from your Slack account ー without having to set up their own accounts.
Nobody ー this setting restricts any action being taken and only allows users to view data.

You might want to choose this option if you intend your doc to be strictly informational and connect data, rather than pushing data out.

After you have signed in to an account you can make changes to the permissions in the Pack’s settings. Expand the account details using the down arrow to the right of that account, and check or uncheck the boxes next to the permissions options as desired. Check out this article for more information on the differences between the options.

Security of individual Packs

In the Gallery listing for each Pack, you’ll see a Security tab. This page details everything you need to know about an individual Pack’s security. Here’s an example using the Jira Pack:

Pack certifications. Packs that have a blue check mark next to their name are Coda certified. This means that the Pack has passed Coda’s quality review check, and the Pack’s maker has a support agreement in place with Coda. Our team has human reviewed certified Packs and their accompanying published docs to ensure they meet our standard of excellence. Maker’s of certified Packs have agreed to respond to support tickets within 48 hours of inquiry, Monday through Friday.
Restricted networks. Packs are only able to interact and share data with the websites that the Pack maker has declared. Here, you’re able to see which domains the Pack can connect to, meaning the Pack can’t siphon data to another domain or access anything it’s not supposed to.
Authentication types. Pack makers, Pack code, and other doc users never have access to your usernames and passwords. Coda encrypts your login information and runs them on behalf of the Pack, so you never have to worry about your credentials being compromised. Here, you’re able to see what authorization protocol is used to securely log in to the respective service, and you can see what URL the Pack uses to pass this information.
Limited data access. Packs are restricted to the data categories that are declared by the Pack maker, meaning Packs cannot access data from the respective service or your doc without permission. In this section, you’re able to see a full list of the Pack’s scopes in the drop down.

Coda certified Packs

Coda certified Packs have passed our standard of excellence for quality and support. Coda certified Packs are recognized by the blue checkmark next to their name. Here’s the standard that these Packs have adhered to:

Quality. Our team has human reviewed each individual Pack and its accompanying documentation to ensure that makers will have an excellent experience. We not only test to ensure the Pack fulfills essential use cases but we thoroughly test the Pack and its published docs for bugs and vulnerabilities.
Support. To be Coda certified, Pack makers must agree to a 48 hour response time to support inquiries, five days a week (Monday - Friday). You can reach makers through the support email provided on the Pack listing page.

If you identify a bug or have a feature request for a Pack, please reach out to the maker directly using the provided support email.

If you are having trouble reaching a Pack maker—especially for a Coda certified Pack—please reach out to Coda Support. You can do so by clicking the question mark icon in the lower right corner of any doc, then choosing Contact support.

Glossary of Pack security terms

Below are definitions for commonly asked about vocabulary.

Name

Definition

Domains

Domains refers to the website that the Pack connects to via API. Pack makers must declare which website they intend to connect to (aka “declared domains”).

Our platform only lets Packs talk to those domains so you know data is not siphoned elsewhere and there isn’t a middleman. If no domain is specified, the Pack is not allowed to talk to the internet at all.

If a Pack wants to have more than 1 domain, Coda currently requires them to manually request a Pack review from our engineering team. Coda wants to make sure that doc users stay in control of how their data moves between services.

Authorization

For Packs where a login is required, authorization tells you which protocol the Pack follows.

OAuth2 is the most popular style of authorization among our Packs (also used by Amazon, Google, Facebook, MSFT, etc. for third party applications). OAuth2 sends Pack users to the Pack’s backing service for a nice login experience when the user tries to install the Pack.

Other authorization methods to services outside of Coda require the user to copy/paste API credentials into Coda.

A few Packs actually use Coda docs as their backing service, and Coda makes that authorization process easy for the user to click through and grant narrowly scoped permissions to the Pack.

Authorization URL

Specific to OAuth2. The authorization URL expresses where end users of a pack will be sent and told to put in their login credentials to the service the Pack talks to.

This ensures that the code is sending your users to the proper service and not www.stealyourpassword.com for example.

Token URL

Specific to OAuth2. When a service confirms your login credentials the service will send a “token” back to Coda. Coda will then validate the token and lets the service pass data through the Pack into your doc. Coda manually reviews any Pack that uses a Token URL that is on a different domain than the Authorization URL, as that is a very unusual need.

Scopes

Specific to OAuth2. Scopes tell you what permissions the Pack has in communicating with the outside service. Some common examples of scope permissions include:

Read: You can bring this information from the service into Coda.
Write: You can send updates back to the service through Coda with this permission.
Offline: You can access the service or a specific types of data when you’re offline.

A Pack can request additional scopes for certain formulas, or introduce new scopes in later versions of a Pack, but every time a new permission is needed, the end user will be sent back to the third party access confirmation page.

FAQs for IT Admins

Jonathan Goldman, head of Packs engineering at Coda, answers your most pertinent questions on Packs and keeping your workspace secure.

Can a Pack maker access my credentials or data?

When I install a Pack, what exactly is it getting access to?

What is the difference between a shared and private account? How can I make sure my teammates can / can NOT take action through my log in?

What are Coda’s best practices for Pack security? Any tips on managing access to data via third party Pack accounts?

Can Enterprise admins control which Packs are accessible within their workspaces?

Yes, admins on Coda's Enterprise plans can control which Packs are available to org members via Pack controls. You can learn all about this feature here.

Related resources