Power-Up Security

We want to ensure that Trello users have a safe and secure time throughout their entire experience using Trello, including while using Power-Ups. To help us achieve this goal, we expect Power-Up developers to do their best in ensuring their own applications are as safe and secure as Trello is. To this end, we're highlighting a number of best practices below.

When security vulnerabilities do occur, we have a policy in place that we'll follow to work with you to get the vulnerability fixed. Public Power-Ups should review and be prepared to respond to incidents as outlined in the Vulnerability Reporting and Developer Expectations below.

Best Practices and Recommendations

Cross-site Scripting

When building HTML from user data (e.g. user defined settings, card names, etc) ensure that the data in and out is being sanitized appropriately. Any user-generated content should be escaped. For example, if you're rendering something called Test <img src=0 onerror=alert(1)> Test what happens?

Read more on XSS here.

API Key Allowed Origins

If your Power-Up makes use of Trello's REST API, you should set your API key's allowed origins properly.

You can manage your API key's allowed origins via the https://trello.com/power-ups/admin page, then access your Power-Up and navigate to the API Key tab.

Proper t.set() Scopes

When making use of t.set() from the Power-Up client library, the shared scope should never be used to store data that should be kept secret.

Data stored in the shared scope is readable by any user who can view the board. If a board is made public then the data in the shared scope will be publicly available to anyone on the internet.

Server Settings

You should put a Content-Security-Policy in place to restrict scripts to only your known allowed origins. Specifically, you should set the script-src directive to exclude unsafe-eval, unsafe-hashes and unsafe-inline.

TLS version 1.2 (or higher) should be used. TLS version 1.2 using AES 256 encryption or higher with SHA-256 MAC is recommended.

HSTS should be enabled with a minimum age of at least one year.

The application must disable caching on all HTTPS pages that contain sensitive data by using no-cache and no-store instead of private in the Cache-Control header.

Backend Server Security

If your Power-Up makes use of a backend service of some sort, you should ensure that the service is as secure as possible.

The service should authenticate and authorize all requests. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.

Access to Trello user data stored by your application and services must be authenticated and authorized. This includes, but is not limited to data stored in:

• AWS S3 buckets

• application databases

t.jwt()

Where possible, we recommend using t.jwt() to secure the communication between your Power-Up and your server. t.jwt() can be used to ensure that a request made by your Power-Up was made on behalf of a particular Trello user.

The application should never ask for Trello user login credentials. Access to Trello user accounts should only occur via the REST API.

The application should not use versions of third-party libraries and dependencies with known vulnerabilities of high or critical severity.

Version Control

No secret data of any sort should be checked into version control. In-particular, make sure that no API tokens are hard-coded anywhere.

It is OK for an API key to be publicly available.

Remove Previous Releases With Known Vulnerabilities

It happens to the best of us. A security researcher finds a bug that can lead to an XSS attack in your code. You act quickly to resolve the vulnerability and deploy a new release that patches it. Your users are now safe right?

Not quite.

Depending on how you are hosting your code, its possible that you are still serving that old release with the vulnerability. For example it might still be accessible via your CDN or in S3. You need to make sure that you remove that release from being served on your domain, otherwise your users are still at risk. You might need to invalidate your CDN or explicitly remove it from S3.

For an in-depth guide on how keeping old releases accessible can be abused we recommend reading Stealing the Trello token by abusing a cross-iframe XSS on the Butler Plugin.

Vulnerability Reporting and Developer Expectations

If a vulnerability is discovered in your Power-Up, we will send an email to the email address used to submit the Power-Up for review.

If the vulnerability exposes direct access to a Trello user's account (especially via a token), the Power-Up will be moderated. A moderated Power-Up will remain enabled on all boards on which it is enabled, but it will never be initialized.

We expect you to respond to the email within five days of it being sent, acknowledging that you are aware of the vulnerability. Failure to respond may result in the Power-Up being de-listed from the Power-Up directory and moderated.