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.

​
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.

​
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.