Application Security
On this page
Overview
Atlas App Services provides a variety of security features to protect your data and prevent unauthorized access to your application. This includes things like:
- Built-in user management
- Data access permissions
- Network security features
- The ability to store and substitute values and secrets
Application Users
You can secure Atlas App Services applications with built-in user management. With App Services's built-in user management, only authorized users can access your App. You can delete or disable users, and revoke user sessions. Users can log in with:
- Existing provider credentials, such as Facebook, Google, or Apple ID
- New credentials with email/password, custom JWT, or custom function authentication
- Anonymous authentication, if you don't need to store user data
You can enable one or more authentication providers in the App Services backend, and then implement them in your client code. You can also link user accounts with client SDKs.
Data Access Permissions
Use Atlas App Services data access rules to grant read and write access to data. Apps that use Atlas Device Sync define data access permissions during the process of enabling Device Sync. Apps that do not use Device Sync can link an MongoDB Atlas data source, and define permissions to perform CRUD operations on that data source.
MongoDB data access rules prevent operations where users do not have appropriate permissions. Users who do not meet your data access rules cannot view or modify data.
Atlas App Services Applications with Sync
When you enable Atlas Device Sync for your App, you define data access rules that determine which data users can read and write. The Sync Mode you select determines which types of permissions apply for your application.
Partition-Based Sync
When you enable Partition-Based Atlas Device Sync, you specify the partition key that gives users access to data. You can define JSON expressions to give users read and write permissions for the partition.
When you access a synced App from a client, you specify the partition value that the logged-in user can access. The user only has access to the partition key and value you define in your app. The user cannot read or write data whose partition key value does not match the conditions you specify when you configure Device Sync.
Flexible Sync
When you enable Flexible Atlas Device Sync, you specify the fields that your client application can query, as well as rules to apply read and write permissions. You can define JSON expressions to give users read and write permissions for specific collections, and define default roles that apply permissions across all collections.
Your client application can query for objects via these queryable fields. Users can then access objects that match the query where they have read or read and write permission to access the objects. Objects that match the query, but where the user does not have read or read and write permission, do not sync to the client application.
MongoDB Atlas Data Sources
When you access MongoDB Atlas through Atlas App Services, you can define roles that enable users to read and modify data. App Services uses a strict rules system that prevents all operations unless they are explicitly enabled.
When you define a role, you create a set of CRUD permissions that Atlas App Services evaluates individually for each document associated with a query. You can set roles to have document-level or field-level access, and you can give roles read or read and write access. App Services blocks requests from roles that do not have permission to search or read data.
When you access MongoDB Atlas through an App with Atlas Device Sync enabled, the permissions you define for Device Sync apply, instead of the role-based permissions you define when you link an MongoDB Atlas data source.
Developer Access
Every Atlas App Services application is associated with a specific MongoDB Atlas organization and project. App Services determines the developer access permissions for a given MongoDB Cloud user based on their assigned project roles in the project that contains an app.
The following table describes the access permissions associated with a given project role:
Project Role | Access Permissions |
|---|---|
Project Owner | Full read-write access for all Apps associated with the project. |
All Other Roles | Read-only access for all Apps associated with the project. |
For more information about adding users and teams to Atlas, see Atlas Users and Teams.
Network Security
Atlas App Services utilizes a range of network security protocols to prevent unauthorized access to your data. This includes:
- Using TLS to secure network requests to and from your application
- Defining IP addreses from which all outbound requests originate
- Letting you define URLs and IP addresses from which inbound requests may originate
Transport Layer Security (TLS)
Atlas App Services uses TLS 1.3 to secure all network requests to and from your application, including:
- Apps that connect from a Realm SDK
- Queries and operations on a linked MongoDB Atlas data source.
The TLS certificate is pre-defined and cannot be customized or disabled.
Firewall Configuration
Atlas App Services only sends requests from the following IP addresses. You can copy this list to an allowlist on your firewall:
13.236.189.10 18.202.2.23 18.210.66.32 18.211.240.224 18.213.24.164 52.63.26.53 54.203.157.107 54.69.74.169 54.76.145.131 18.192.255.128 18.157.138.240 18.158.38.156 52.220.57.174 18.140.123.126 13.251.182.174 65.0.112.137 3.6.231.140 13.234.189.107
You can find this information in computer-friendly formats at these URLs:
- JSON
- https://www.mongodb.com/docs/realm-sdks/mongodb/RealmPublicIPs.json
- CSV
- https://www.mongodb.com/docs/realm-sdks/mongodb/RealmPublicIPs.csv
The above IP list only applies to outgoing requests from App Services functions, including triggers and HTTPS endpoints that make outgoing requests.
For requests that originate from the Sync server, we recommend allowlisting the entire subnet of the app's Deployment Region and cloud provider. You can find the Deployment Region in the Atlas App Services UI under App Settings > General > Deployment Region.
Allowed Request Origins
You can define this configuration option in the
app-level realm_config.json file. This field accepts an array of
URLs that incoming requests may originate from. If you define any allowed
request origins, then App Services blocks any incoming request from
an origin that is not listed.
IP Access List
Atlas App Services allows client requests from the enabled entries in the app's IP access list. Allowed requests will still use App Services's authentication and authorization rules. When you add IP access list entries, App Services blocks any request originating from an IP that is not on the access list.
By default, any newly-created App allows access from any client IP by adding an access list entry for 0.0.0.0/0. If you delete this entry, no client can access your App from any IP address.
API Access List
When you create an API key, you can specify IP addresses that can use this API key to access your project or organization. If you specify an IP address, App Services blocks any request originating from an IP address that is not on the access list.
All internal communication between App Services and Atlas is encrypted with x509 certificates.
Values and Secrets
Atlas App Services enables you to define values and secrets that you can access or link to from your application. This enables you to remove deployment-specific configuration data and sensitive information from your app's business logic. Instead, you refer to it by name and App Services substitutes the value when executing your request.
Summary
- Built-in user management handles authentication and ensures only logged-in users can access your App.
- Data access permissions enable you to specify read and write permissions for Atlas Device Sync, linked MongoDB Atlas data sources, and developers building your apps.
- Network security features enable you to guard against unauthorized access from unknown IP addresses or URLs.
- Store values and secrets and refer to them by name to remove sensitive information from your business logic.