Given that customers of Magic Patterns may provide their code in order to best use Magic Patterns for legitmate business practices, the Magic Patterns security model is very important and held in the highest standard. The goal of Magic Patterns’ security model is to ensure the security and integrity of all of its managed data as well as all associated operations.
This means that data at rest and in transit must be secure from eavesdropping or tampering. All clients must be authenticated and authorized to access relevant data. Additionally, all interactions must be auditable and traced uniquely back to their source.
Magic Patterns’ threat model spans communication, storage, response mechanisms, failover strategies, and more.
- Eavesdropping on communications: Magic Patterns ensures end-to-end encryption for all client interactions with the Magic Patterns API.
- Tampering with data (at rest or in transit): magic Patterns implements data integrity checks to detect tampering. If inconsistencies are found, Magic Patterns aborts transactions and raises alerts.
- Unauthorized access (lacking authentication/authorization): Magic Patterns mandates rigorous authentication and authorization checks for all inbound requests.
- Actions without accountability: Magic Patterns logs all project-level events, including policy updates, queries/mutations applied to secrets, and more. Every event is timestamped and information about actor, source (i.e. IP address, user-agent, etc.), and relevant metadata is included.
- Loss of service availability or secret data due to failures: Magic Patterns leverages the robust container orchestration capabilities of Fly.io and the inherent high availability features of MongoDB to ensure resilience and fault tolerance. By deploying multiple replicas of Magic Patterns application on Fly.io, operations can continue even if a single instance fails.
- Unrecognized suspicious activities: Magic Patterns monitors for any anomalous activities such as authentication attempts from previously unseen sources.
External threat overview
Magic Patterns’s architecture consists of various systems:
- Magic Patterns API
- Storage backend
- Magic Patterns Web UI
The Magic Patterns API requires that the Magic Patterns Web UI are authenticated and authorized for every inbound request that accesses customer data.
The storage backend used by Magic Patterns is also untrusted by design. All sensitive data is encrypted either symmetrically with AES-256-GCM or asymmetrically with x25519-xsalsa20-poly1305 prior to entering the storage backend, depending on the context either on the client-side or server-side. Moreover, Magic Patterns communicates with the storage backend over TLS to provide an added layer of security.
Internal threat overview
Within Magic Patterns, a critical security concern is an attacker gaining access to sensitive data that they are not permitted to, especially if they already has some degree of access to the system. There are currently two authentication methods categories used by clients for where we apply robust authentication and authorization logic.
This token category is used by users and included in requests made from the Magic Patterns Web UI or elsewhere to the Magic Patterns API.
Each token is authenticated against the API and mapped to an existing user in Magic Patterns. If no existing user is found for the token, the request is rejected by the API. Each token assumes the permission set of the user that it is mapped to. For example, if a user corresponding to a token is not allowed access to a certain organization or code, then the token is also not be valid for any requests concerning those specific resources.
Magic Patterns leverages the robust container orchestration capabilities of Fly.io and the inherent high availability features of the storage backend (i.e. MongoDB) to ensure resilience and fault tolerance.
- Fly.io: By deploying multiple replicas of Magic Patterns application on Fly.io, operations continue even if a single instance fails. Fly.io Services facilitate load balancing, effectively distributing traffic across your application’s instances and ensuring optimal performance.
- Storage backend: MongoDB supports replica sets, which provide data redundancy and automatic failover for the underlying database.
- If using Magic Patterns, data is stored in a Mongo Atlas cluster with storage autoscaling and cluster tier autoscaling enabled; as you’d expect, the cluster sits on a dedicated node.
Together, Fly.io’s self-healing mechanisms and MongoDB’s failover capabilities work to create a highly available and fault-tolerant application capable of recovering gracefully from unexpected failures.
A snapshot is a complete copy of data in the storage backend at a point in time.
If using Magic Patterns, snapshots of MongoDB databases are taken regularly; this can be enabled on your own storage backend as well.
Magic Patterns utilizes the latest HTTP security headers and employs a strict Content-Security-Policy to mitigate XSS.
JWT tokens are stored in browser memory and appended to outbound requests requiring authentication; refresh tokens are stored in
HttpOnly cookies and included in future requests to
/api/token for JWT token renewal.
Magic Patterns supports authentication methods with Figma or GitHub.
Employee data access
Whether or not Magic Patterns or your employees can access data in the Magic Patterns instance and/or storage backend depends on many factors how you use Magic Patterns:
Using Magic Patterns’s managed service, Magic Patterns means delegating data oversight and management to Magic Patterns. Under our policy controls, employees are only granted access to parts of infrastructure according to principle of least privilege; this is especially relevent to customer data can only be accessed currently by executive management of Magic Patterns. Moreover, any changes to sensitive customer data is prohibited without explicit customer approval.
Please email firstname.lastname@example.org if you have any specific inquiries about employee data access policies.
Get in touch
If you have any concerns about Magic Patterns or believe you have uncovered a vulnerability, please get in touch via the e-mail address email@example.com. In the message, try to provide a description of the issue and ideally a way of reproducing it. The security team will get back to you as soon as possible.