Rate this page:
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.
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 what happens?
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 https://trello.com/app-key.
When making use of t.set() from the Power-Up client library, the scope should never be used to store data that should be kept secret.
Data stored in the scope is readable by any user who can view the board. If a board is made public then the data in the scope will be publicly available to anyone on the internet.
You should put a in place to restrict scripts to only your known allowed origins. Specifically, you should set the directive to exclude , and .
We recommend checking out the Laboratory by Mozilla extension. Laboratory is an Firefox extension that helps you generate a proper Content Security Policy (CSP) header for your website.
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 and instead of in the header.
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:
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.
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.
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?
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.
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.
Lack of communication from you
If you do not acknowledge and respond to the security issue report within 30 days, the Power-Up may be un-enabled from boards on which it is enabled, and permanently de-listed from the Power-Up directly.
Rate this page: