App security guidelines

We prioritize the security of our Miro product and Marketplace. Every new plugin or app and its updates undergo a rigorous verification and approval process. These security requirements and recommendations are designed to maintain high security and quality for Miro Marketplace apps. This guideline focuses on key areas such as data privacy, performance impact, and vulnerabilities.

Requirements

Authentication and authorization

• Use OAuth 2.0 authorization. Do not ask users for their credentials.
• Each request must be authenticated and authorized.
• Authenticate and authorize access to Miro User Data that your app stores.

Session cookies

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

Data storage

• Do not store Miro credentials.
• Do not hardcode API keys in the source code.
• If you must store data, use high-load ready databases like S3.
• Encrypt any confidential information you store.
• Do not cache sensitive data. Use no-cache and no-store values in the Cache-Control header for HTTPS pages with sensitive data. The Cache-Control header should look like this:
  • HTTP/1.1:
  • Cache-Control: no-cache, no-store
• Avoid collecting or storing user data that is not necessary for the application to function.

Network and server configuration

• Use TLS version 1.2 or higher to encrypt all application traffic. Check your TLS version using Qualys SSL Labs in the Protocols section.
• Ensure HTTPS-only connections on all app pages.
• Enable HSTS with a max-age of at least one year. Check your TLS version using Qualys SSL Labs in the Protocol Details section. The “Strict Transport Security (HSTS)” field should have a value of max-age ≥ 31536000 and the "includeSubDomains" parameter should be enabled.

Domain control

• Ensure TLS certificates on your domain are valid. Certificates should be signed by a Certificate Authority trusted by major browsers. Check using your browser or Qualys SSL Labs.
• Maintain control of domains and subdomains where your application is hosted.
• DNS configurations for subdomains should point only to services in use.

Logging

• Avoid logging secrets, tokens, and other sensitive information.

Performance

• Ensure your app does not negatively impact the overall performance of the Miro Service.

Vulnerabilities

• Do not use vulnerable libraries.
• Ensure there are no medium, high, or critical vulnerabilities in your app. Check this with OWASP Dependency-Check.

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 safety before use.
• Encode all output to process data as data, not as code.
• Avoid unrestricted file input.

Session cookies

• Session cookies should have high entropy to prevent them from being guessed or brute-forced.
• Invalidate session cookies on logout.

Cryptography

• Use recommended algorithms, such as AES 256 in GCM mode. Avoid creating your cryptographic algorithms.
• Initialize cryptographic keys using a secure random number generator.

Network configuration

• Recommend using TLS version 1.2 with AES 256 encryption or higher and SHA-256 MAC.
• Ensure that HTTP methods like TRACE are disabled if not in use.

Egress traffic

• Properly filter all egress traffic from your app and restrict access to internal resources.
• If possible, allowlist domains for egress traffic.
• Ensure that any domains or subdomains belonging to the app are owned and not left dangling.
• For Connect apps, ensure the baseUrl configured in the app’s descriptor file is valid and owned by the app.

Logging

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

Information leakage

• Protect OAuth tokens and client secrets from being exposed in emails, client-side JavaScript, error messages, or stored in public code repositories.
• Prevent secrets from being leaked by the Referer header to third parties: implement a 302 found redirect, especially when handling authentication tokens.
• For Connect apps, ensure that the shared secret is stored securely and not exposed on the client-side or server-side in error messages.