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. Prefer passkeys over TOTP to prevent domain spoofing attacks, as passkeys are bound to the origin domain. Consider action-based enforcement (MFA for sensitive actions such as signing or exporting keys) to protect users if credentials are compromised. |
| Recovery Shares & Cloud backups | Recommended | Ensures secure and accessible backup options for account recovery. Use passcode protection for backup wallet shares to add an additional security layer. If users lose their passcode, they cannot recover their wallet. |
| Passcode | Recommended | Adds an additional security factor on the user-share for Dynamic Embedded wallets with TSS-MPC. If users lose their passcode, they will lose access to their wallet. See Password encryption. |
| 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. For verifying JWTs on your backend, see Tokens. |
| Roles & Permissions (Dynamic Dashboard) | Recommended | Limit who in your organization can perform read, write or administrative privileges in your account. You can also lock access to your environment’s APIs from the dashboard when needed. |
| Email notifications | Recommended | Enable email notifications for security-related events to receive alerts about important security events that require your attention. |
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 of 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.
Auth Token Length and Storage
Authentication and authorization use Dynamic’s auth token (a JWT). Recommendations:- When the token expires, the user’s session ends (they are logged out) and they must re-authenticate. The 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 auth tokens. Stored or logged tokens could be used to access user funds.
- Note: Without Action-Based MFA, embedded wallet access is protected only by the auth token and the user’s login method—use short-lived tokens to limit risk.
Backend JWT Security
Critical: A leaked JWT could lead to access to user funds and wallet by an external party. Anyone who obtains a valid JWT can perform any action the user can perform, including signing transactions, exporting keys, and draining wallets. If you send JWTs to your backend, secure your backend infrastructure:- Validate JWTs on every request. Do not trust client-provided JWTs without verification.
- Use HTTPS/TLS for all backend communications. Never transmit JWTs over unencrypted connections.
- Store JWTs securely in memory only. Do not persist JWTs to databases, logs, or file systems.
- Never log JWTs. Logged JWTs could be used to access user funds if extracted from log files.
- Implement proper access controls. Verify that the authenticated user (identified by the JWT) has permission to access the requested resource.
- If a JWT is leaked, immediately revoke existing tokens using the revoke sessions feature in the dashboard.
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)
Prefer Passkeys for MFA
- Use passkeys instead of TOTP for MFA when possible. Passkeys are cryptographically bound to the origin domain, preventing domain spoofing attacks.
- TOTP codes can be phished if users enter them on malicious domains that mimic your application.
- Passkeys use WebAuthn and verify the domain origin, making them resistant to phishing and domain spoofing attacks.
- Configure passkeys in the dashboard under Security Settings. See End-User MFA Configuration for setup instructions.
Protect Backup Wallet Shares
- Enable passcode protection for backup wallet shares. This adds an additional encryption layer to backup shares stored in cloud services. See Password encryption.
- Passcode-protected backups require the passcode to decrypt shares during wallet recovery. This prevents unauthorized access to backup shares even if cloud storage is compromised.
- Educate users on the importance of remembering their backup passcode. Lost passcodes cannot be recovered and will prevent wallet recovery.
Enable Email Notifications
- Configure email notifications for security-related events in your environment. Email notifications alert you to important security events that require your attention, such as new sign-ins, session changes, and failed login attempts.
- Enable email notifications in the Security Settings page of the dashboard.
- Monitor email notifications regularly to detect potential security issues early.
- See Security Settings - Email Notifications for configuration instructions.
Familiarize Yourself with Failsafe Measures
A security incident that requires these measures should never happen — but in the extreme case that it does, you must act quickly. Review and understand the available failsafe measures before you need them.Revoke Sessions
- The revoke sessions action invalidates all active user sessions in an environment. This is a failsafe action you can trigger at any time.
- Revoked sessions cannot be used for wallet transactions or authenticated requests. Users are logged out when the SDK detects the revoked session on their next request.
- This action cannot be undone. Use it when you suspect a security breach or need to immediately invalidate all user sessions.
- Access the revoke sessions feature in the Security Settings page of the dashboard.
- See Security Settings - Revoke Active Sessions for details.
Lock Your Environment Access
- You can lock access to an environment from the dashboard so that its APIs cannot be used.
- This is useful if you suspect compromise or need to immediately stop all traffic to an environment.
- Lock and unlock are available under Account Security in the Security Settings page.
- Only the owner of the organization can see and use the lock environment option.
Private Key Export Controls
- Consider disabling private key exports for embedded wallets if your use case requires additional security controls. We recommend enabling Action-Based MFA for key exports so that exporting a private key requires a second factor.
- Private key exports are enabled by default. You can disable them in the Embedded Wallets settings under the Security section.
- Disabling private key exports prevents users from exporting keys, which reduces the risk of key exposure through phishing, malware, or user error.
- Disabling exports limits user portability. Users cannot migrate their wallets to other services if exports are disabled.
- Evaluate your security requirements and user needs before disabling exports. For high-security applications or enterprise use cases, disabling exports may be appropriate.
- If you disable exports, clearly communicate this limitation to users during onboarding.
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.
Rate Limits
Familiarize yourself with Dynamic’s rate limits for IP addresses, project environments, and endpoints you are using. Refer to Rate Limits for more information.Static IP Addresses
Where applicable, we recommend using Dynamic’s static IP addresses in your IP allowlist. For instance, when using our ZeroDev integration or external authentication you can add Dynamic’s static IP addresses to your IP allowlist to restrict access.Dynamic’s IP addresses
52.204.85.8754.145.74.8107.20.170.23852.206.26.563.232.2.6744.213.187.169
These IP addresses do not apply to webhook messages. For webhook IP addresses, see the section below.
Webhook IP addresses
98.89.223.16444.220.108.17534.194.252.13234.195.215.4344.198.112.228