App Security

All newly created apps start in out in development mode. You can use the App Dashboard to switch any app between development mode and public mode, except for test apps, which are always in development mode.

Apps in development have access to all permissions and features, including those that normally would require approval from the Login Review process. However, when an app is in development mode, the following restrictions will be applied:

• The app can only be used by users who have a role on the app.
• App users can only access the data of users who have a role on the app.

Some products, such as the Pages API, place additional restrictions on apps in development mode.

App Roles

You can add a user to an app with one of four different roles: administrator, developer, tester or Insights user. Each role provides a different set of permissions to the user. We recommend that you only give as much access to a user as they need. This provides greater security for your app and opens it up to less harm in the situation that the user’s account is compromised.

Administrator – Administrators have complete access to an app. They can change all app settings, reset the app secret, delete the app, and view Credits and Insights. Administrators can also add/remove other users to/from the app and change their permissions. Administrators of apps should only add other users as administrators if they are fully trusted and must have full control of the app.

In order to add a user as an administrator of an app, the user must have a verified Facebook developer account.

Developer – Developers have access to the app and all its technical settings that are needed to run, edit and test the app. Developers can modify all technical settings for an app, which are accessible through the App Dashboard. They can also see Insights for the app.

Unlike administrators, they can’t:

• Reset app secret key
• Delete an app
• Add or remove other users as developers, testers or administrators

In order to add a user as a developer of an app, the user must have a verified Facebook developer account.

Tester – Testers can only test the app in development mode. They cannot edit any app settings, give other users access to the app or access Insights for the app. The tester role is the most harmless and hence should be used for all users who need to test the app in development mode. In public mode all users will have access to the app.

Analytics User – Analytics Users can only access analytics for your app. They cannot otherwise interact or log into the app while in development mode and do not have access to edit any of the app’s settings.

App Settings Security

We often hear of cases where an app is taken over by an impostor who comes in and changes the app settings, causing much pain to users and developers until this is discovered and fixed.

IP Address Whitelist – We allow you to specify a whitelist of IP addresses that must be used to update the app settings. This helps prevent attacks by ensuring that only developers using the company IP addresses can update app settings.

This whitelist can be set in the Advanced tab of your app settings in the App Dashboard.

Once specified, any app update request coming from a non-whitelisted IP address is rejected. This whitelist applies to updates made using API as well as the UI.

Update Notification – In the event that such a takeover does take place, we have built a notification system to expedite discovery and recovery from such takeovers. This notifies relevant individuals when any app settings are changed using the App Dashboard. The notification contains information about what change was made and by whom.

An app can register an email address to which these notifications should be sent in the Advanced tab of app settings.

Server Whitelist

Restrict some of API calls to come from a set of white-listed servers.

Enable and/or disable any authentication flows that the app does not use to minimize attack surface area.

• Use code-generated short-term access tokens in clients instead of client-generated tokens or server-provided long-term tokens. The code-generated short-term access tokens flow requires the app server to exchange the code for a token, which is more secure than obtaining a token in the browser. Apps should prefer using the this flow whenever possible to be more secure – if an app only enables this flow, malware running on a user’s computer cannot obtain an access token to abuse.
• Disable Client OAuth Login if your app does not use it. Client OAuth Login is the global on-off switch for using OAuth client token flows. If your app does not use any client OAuth flows, which include Facebook login SDKs, you should disable this flow. Note, though, that you can’t request permissions for an access token if you have Client OAuth Login disabled. This setting is found in the Products > Facebook Login > Settings section of the App Dashboard.

Facebook Crawler

A number of platform services such as Social Plugins and Open Graph require our systems to be able to reach your web pages. We recognize that there are situations where you might not want these pages on the public web, during testing or for other security reasons.

Social Plugin Confirmation Steps

In order to protect users from unintentionally liking content around the web, our systems will occasionally require them to confirm that they intended to interact with one of our Social Plugins via a “confirm” dialog. This is expected behavior and once the system has verified your site as a good actor, the step will be removed automatically.

SSL

If you’re connecting to Facebook’s servers your client must:

• Use TLS. SSLv3 is no longer supported as of October 14, 2014.
• Be able to verify a certificate signed using sha256WithRSAEncryption as of Oct 1, 2015.

Most modern clients can meet these requirements. However, older clients may not be new enough, especially in embedded applications like consoles. IE6 in Windows XP SP2 and earlier also does not meet these requirements.