DocumentationResourcesMarketplaceCommunity
Build your app
These docs are for v1.0. Click to read the latest docs for v2.0.

Security Guidelines

Suggest Edits

Introduction

We take great care of the security of our Miro product and our Marketplace in particular. Each new plugin and its subsequent updates go through a verification and approval process. We created this list of security requirements and recommendations to ensure the Miro Marketplace apps' high security and quality. This guideline focuses on the main pain-points: data privacy, performance impact, and vulnerabilities.

We separated the document into two parts: Requirements and Recommendations.

Requirements (main blockers that might affect the publication of your app)

Authentication and authorization

  • Use OAuth 2.0 authorization. Don’t ask users for their credentials.
  • Each request must be authenticated and authorized.
  • You must authenticate and authorized access to Miro User Data that your App stores.

Session cookies

  • HttpOnly & Secure flags must be set. You can detect the absence of these flags using a vulnerability scanner, such as Burp Suite.

Data storage

  • Do not store Miro credentials.
  • API keys must not be hardcoded in the source code.
  • If you must store data, use high-load ready databases, S3.
  • You must encrypt any confidential information that you store.
  • Do not cache sensitive data. All HTTPS pages with sensitive data must use no-cache and no-store values in the Cache-Control header. You can check this by reviewing the request headers on pages with sensitive data. The Cache-Control header must look like this:
  • HTTP/1.1:
  • Cache-Control: no-cache, no-store
  • Do not collect or store user data that is not necessary for the application to function.

Network configuration/Server configuration

  • You are required to use TLS version 1.2 or higher to encrypt all application traffic. You can check your TLS version using Qualys SSL Labs in the Protocols section.
  • There must be HTTPS-only connections on all App pages.
  • HSTS must be enabled with a maximum age of at least one year. You can check your TLS version using Qualys SSL Labs in the Protocol Details section. The “Strict Transport Security (HSTS)” field must have the value of max-age greater than or equal to 31536000 and the "includeSubDomains" parameter must be enabled.

Domain Control

  • TLS certificates on your domain must be valid. You can find the certificate with help of your browser or using Qualys SSL Labs. Your certificate must be signed by a Certificate Authority which is trusted by the major browsers.
  • You must maintain control of domains and subdomains where your application is hosted.
  • Your DNS configuration for subdomains must point to services that are in use.

Logging

  • Ensure that secrets, tokens, and other sensitive information are not logged.

Performance

  • Your App must not affect the whole Miro Service performance.

Vulnerabilities

  • You must not use vulnerable libraries.
  • There must not be medium, high, or critical vulnerabilities in your App. You can check this with OWASP Dependency-Check.

Recommendations (not blockers, but we suggest you follow these recommendations)

Authentication and authorization

  • Grant scopes to your App in accordance with the principle of least privileged access.

Secure input and output handling

  • Validate and sanitize all input to ensure that data is safe prior to use.
  • Encode all output. The data must be processed as data and not as code.
  • Avoid unrestricted file input.

Session cookies

  • Session cookies must have high entropy so that they cannot be guessed or brute-forced.
  • Ensure that session cookies are invalidated on logout.

Cryptography

  • Use recommended algorithms, such as AES 256 in GCM mode. Do not create cryptographic algorithms.
  • Initialize cryptographic keys using a secure random number generator.

Network configuration

Egress traffic

  • Ensure that all egress traffic from your app is properly filtered and access to internal resources is restricted.
  • Allowlist domains for egress traffic, if possible.
  • Ensure that any domains or subdomains belonging to the App are owned and are not left dangling.
  • For Connect apps, ensure that the baseUrl configured in the app’s descriptor file is valid and owned by the app.

Logging

  • Log events and activities such as PRs being merged without approval and admin actions, such as creating or modifying existing users, new instances being created, admin logins, and alike.

Information leakage

  • Do not expose OAuth tokens. OAuth client secrets must be handled carefully. Client secrets must not be distributed in emails, client-side Javascript, or error messages and must not be stored in public code repositories.
  • Ensure that secrets are not leaked by the Referer header to third-parties: endpoints should implement a 302 found redirect. This is particularly important when app endpoints are handling authentication tokens.
  • For any Connect apps, ensure that the shared secret is stored securely and not exposed on the client-side or server-side in error messages.

Updated about 2 years ago