Security
Best Practices
Overview
At Dynamic, we prioritize flexibility and choice. While we offer a range of tools to enhance security for your applications and wallets, we recognize that not every feature may align with your risk profile and use case. For instance, you can require an MFA at sign-up, but this extra step might be unnecessary for users who haven’t yet built up many assets. That’s why MFA is recommended rather than required for using Dynamic. As a developer, you have the freedom to evaluate what best suits your risk profile, business requirements, and user preferences. We encourage you to implement the highest security practices that align with your application and UX requirements Dynamic powered Embedded Wallets are self-custodial by design. It is important that you determine how to use them and evaluate what structure works best for your business and users. While we prioritize flexibility and choice, we maintain certain requirements and recommended best practices to ensure the security for all developers, regardless of their level of sophistication.| Security Measure | Requirement Level | Description |
|---|---|---|
| Allowed domains (CORS origin) | Recommended | Prevents malicious domain impersonation. Required in certain scenarios. |
| Content Security Policies (CSP) | Recommended | Mitigates Cross-Site Scripting (XSS) attacks. |
| Third Party App connection checks (Global Wallet Kit specific) | Required for Global Wallets | Helps prevent users from connecting to malicious third party applications |
| Multi-Factor Authentication (MFA) | Recommended | Enhances account security, excluding SMS as a sole method. |
| Recovery Shares & Cloud backups | Recommended | Ensures secure and accessible backup options for account recovery. |
| Passcode | Recommended | Adds an additional security factor on the user-share for Dynamic Embedded wallets with TSS-MPC. |
| Transaction security checks | Recommended | Provides added protection for users by checking if a transaction may interact with a known malicious address or is requesting permissions beyond what is expected. If using Dynamic Global wallets, this is required. |
| Transaction simulation | Recommended | Simulates the transaction to ensure users double check the asset amounts and destinations prior to completing an activity. |
| Cookie-based authentication | Recommended | This can mitigate certain types of attacks, such as session hijacking by making the JWT not directly accessible or modifiable by client-side scripts. |
| Roles & Permissions (Dynamic Dashboard) | Recommended | Limit who in your organization can perform read, write or administrative privileges in your account. |
Shared Responsibilities
Security is a collaborative effort between Dynamic, developers and end-users. While Dynamic implements robust security measures to safeguard user assets and ensure a secure infrastructure, it also requires developers to actively contribute and continuously improve security practices. Dynamic provides foundational security measures such as mitigating XSS attacks, preventing phishing attempts, and utilizing Secure Enclaves for sensitive operations. However, developers play a crucial role in enhancing security by implementing additional measures like multi-factor authentication, continuous transparent communication, and proactive monitoring. Developers should give Dynamic a heads up ahead heightened traffic periods so we can recommend or enhance protections Dynamic is SOC 2 Type II compliant and regularly completes penetration testing and external security audits from Cure53. Dynamic also has an ongoing bug bounty program with HackerOne. All data with Dynamic is transmitted with encryption using HTTPS and similar protocols. Furthermore, all data is securely stored with encryption-at-rest using AES-256 or higher standards. Dynamic-powered embedded wallets are non-custodial, meaning they are always end-user owned and controlled. Only the end-user has ownership and access to their wallet private keys. For a more detailed description of Dynamic-powered embedded wallets, you can review the architecture and security handling here. Together, we work towards creating a resilient ecosystem that prioritizes user protection and maintains trust in our services. Here are a few ways you can help:Protect Developer Credentials
- Limit and manage access to the Dynamic Dashboard and API tokens.
- Use Dynamic’s role-based permissions to restrict employee actions. Learn more here.
- Require employees to use a time-based one-time password (e.g., Google Authenticator) for accessing the Dynamic dashboard and features. Contact us for access to this feature.
Secure Storage of Dynamic API keys
- Store Dynamic’s API tokens securely and minimize access to these credentials.
- They should only be used on the backend and never shared on the client side.
- Institute an internal policy within your organization to rotate Dynamic API keys regularly.
JWT Length and Storage
- When the JWT expires a user’s session ends (user is logged out) so they will have to re-authenticate once it expires. The JWT token has a maximum lifetime of 30 days. Configure this to the shortest acceptable time to balance security and user experience. More details here.
- Never save or log user JWTs. Note: When using Dynamic-powered embedded wallets without transactional MFA, it’s important to limit the shelf life of the JWT since the wallet is primarily gated by the JWT and the method used by the user to log in.
Implement a Code Review Process
- Ensure another employee approves new code before deployment.
- Establish policies to control who can push code to production.
Mitigate XSS Attacks
- Use content security policies on the frontend.
- Implement TLS and HTTPS for all requests.
- Limit permissible JavaScript, set context headers properly, and avoid open redirects.
- If you enable the frame-src CSP, then you need to perform this whitelisting (learn how here).
- Enforce a strict Content Security Policy (CSP). Refer to this guide for more information.
Enhance CORS Security
- Add specific origins for CORS to protect your environment from unauthorized websites using your public environment key.
- Avoid using wildcards in favor of explicit domains.
- Be especially strict with your live environment (e.g don’t have localhost etc)
Ease of Seed Phrase Export (using Dynamic-Powered embedded wallets)
- Make it easy and readily available for users to export their seed phrase and consider Including it as a step in your sign-up flow.
- Educate Users on security and how you intend to communicate with them
- Clearly communicate to users that neither Dynamic nor any associated parties will ask for private keys or encourage sharing this information.
- Specify the forms of communication and types of interactions users can expect.
Addressing Potential Risks - internal employee account accessed
If an employee account is compromised and best practices are not followed, there are several risks:- Malicious code could be deployed to your application that could attempt to drain user wallets on their next login.
- Unauthorized activities could be conducted using acquired JWT and session key.