In addition to the Developer Platform Glossary and Developer Data Security Best Practices guide, the following provides details about Meta’s expectations for how developers should protect User Data and/or Device User Data. You should be aware of this information because it significantly impacts the technical review of your app.

In order to be compliant with Section 6 of the Developer Data Use Policy, your organization should have information security practices in place that consider your people, processes, technology, assets, and risks. These practices ensure that your organization has taken steps to protect the confidentiality, integrity, and availability of User Data and/or Device User Data. You should understand the risks related to storing and/or transmitting User Data and/or Device User Data. To prevent the unauthorized access or loss of User Data and/or Device User Data, you are expected to have the following information security measures in place:

You should use known industry information security standards to inform your Information Security Practices. An information security standard is a framework that lays out a comprehensive plan for designing, enacting, and operating effective security for your organization. The following are a few examples of useful industry security standards.

Meta does not require you to follow a particular Information Security Standard or obtain a particular data security certification, but here are a few examples:

Meta generally expects that all User Data and/or Device User Data stored at rest is encrypted. Encryption at rest protects data by transforming it into an unreadable format when it is saved to storage. Even if an unauthorized actor gets access to the encrypted disks or files, they will not be able to read the data unless they also have the key to decrypt it.

Encryption at rest is enforced when you:

Data that is not written to storage does not need encryption at rest. You may be able to reduce the complexity of encryption at rest by identifying storage destinations (for example, log files) where User Data and/or Device User Data does not need to be stored and changing your software or processes to remove this data from those unnecessary data stores.

Meta generally expects that all User Data and/or Device User Data is encrypted in transit. Encryption in transit protects data by transforming it into an unreadable format when it is sent across network connections, for example, using TLS 1.2 or alternatives that provide equivalent network communication security.

Encryption in transit is enforced when you:

An example of how to enforce encryption in transit in AWS can be seen in the Amazon Web Services (AWS) documentation.

Testing software for vulnerabilities and security issues helps you find and fix these issues as soon as possible. To help with this, Meta runs a vulnerability scan on your app binary at upload. However, if you store User Data and/or Device User Data on non-Meta servers, you should have practices in place to manage vulnerabilities and perform security testing for any software and hardware that you maintain. Some best practices to consider include the following:

No matter how a vulnerability is discovered, it should be triaged and resolved according to its priority, especially for critical, high, and medium severity vulnerabilities.

Credentials and access tokens are sensitive because they are used to authenticate access to services like APIs. If a malicious actor is able to read an access token, they can impersonate the associated user to get unauthorized access to data.

The following can help you protect these sensitive credentials and tokens:

Multi-Factor Authentication (MFA) requires a person to provide two or more forms of authentication before they can gain access. Examples of this include using a token from an authenticator app or an SMS message sent to a user’s phone. Requiring MFA reduces the risk of malicious actors being able to compromise accounts and exploit that access to get into your system.

One way to enforce MFA for remote access is to require a Virtual Private Network (VPN) connection and then require MFA for access to the VPN. Alternatively, you may be able to define a group policy for all users that requires MFA and blocks other authentication types. You’ll need to consult your provider(s) documentation for instructions on how to require MFA in your environment. An example of a policy template that can be used to require MFA can be found in the Amazon AWS Identity and Access Management tool documentation.

Identity providers such as Microsoft AzureAD, Okta, or other tools for the purpose of centralizing administration of user accounts.

Regardless of the technical implementation you choose, the following principles should be considered:

Keep your software up to date to keep malicious actors from exploiting security vulnerabilities. This includes the software running on your servers, within your applications, and on the devices that the people in your organization use to do their work. Some best practices to consider include the following:

The following are a few examples of various tools and technologies used to keep software up to date.

Production systems handle legitimate requests of your users but are also reachable directly by malicious actors. Some best practices to consider include the following:

To more easily maintain systems as discussed above, the following are some additional best practices to consider:

Consistent monitoring practices of access logs can help maintain better control over your systems. Some best practices to consider to monitor access to Oculus and/or Device User Data include the following:

Should you identify unauthorized access to User Data and/or Device User Data, you should have processes in place to triage and respond to events that may compromise the confidentiality, integrity, or availability of the data. Some best practices to consider include the following: