App security guidelines
Learn about the security verification and approval process for apps on the Miro Marketplace.
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. Miro reserves the right to review an app at any time to ensure that it is in line with our security requirements and recommendations.
This guideline focuses on key areas such as data privacy, performance impact, and vulnerabilities.
Requirements
1. 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.
2. Session cookies
HttpOnly
&Secure
flags must be set. Detect the absence of these flags using a vulnerability scanner, such as Burp Suite.
3. 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.
- Avoid collecting or storing user data that is not necessary for the application to function.
4. 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.
5. 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.
6. Logging
- Avoid logging secrets, tokens, and other sensitive information.
7. Performance
- Ensure your app does not negatively impact the overall performance of the Miro Service.
8. Vulnerabilities
- Do not use vulnerable libraries.
- Ensure there are no medium, high, or critical vulnerabilities in your app. Check this with OWASP Dependency-Check.
Headers and server configuration
Miro requires the following security headers:
Security Header | Value | Purpose | Notes for cross-domain apps |
---|---|---|---|
Strict-Transport-Security (HSTS) | max-age=31536000; includeSubDomains; preload | Enforces HTTPS | Ensure all domains support HTTPS before enabling. |
Referrer-Policy | strict-origin-when-cross-origin | Controls referrer info exposure | Balances security and usability when sending referrer data. |
X-Content-Type-Options | nosniff | Prevents MIME sniffing | No impact on cross-domain functionality. |
Cache-Control | no-cache, no-store | Prevent caching of potentially sensitive information. Should be sent with all server responses. |
Requirements and recommendations for application headers should be reviewed using a tool like https://securityheaders.com.
Recommendations
1. Authentication and authorization
- Grant scopes to your app in accordance with the principle of least privileged access.
2. 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.
3. Session cookies
- Session cookies should have high entropy to prevent them from being guessed or brute-forced.
- Invalidate session cookies on logout.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
Headers and server configuration
Miro recommends the following security headers:
Security Header | Value | Purpose | Notes for cross-domain apps |
---|---|---|---|
Content Security Policy (CSP) | default-src 'self' https:; script-src 'self' 'unsafe-inline' https://trusted-cdn.com; connect-src 'self' https://api.trusted-domain.com; | Prevents XSS & data injection | Adjust connect-src for required API domains; avoid unsafe-inline where possible. |
X-Frame-Options | SAMEORIGIN | Prevents clickjacking | Use CSP frame-ancestors instead if embedding across domains is required. |
Permissions-policy | geolocation=(), microphone=(), camera=(), payment=() | Restricts browser features | Adjust based on app needs. |
Requirements and recommendations for server configuration should be checked using a tool like https://ssllabs.com/ssltest.
Updated 12 days ago