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:
Note that some products, such as the Pages API, place additional restrictions on apps in development mode. Refer to each products documentation to find out if it has additional restrictions.
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.
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.
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:
In order to add a user as a developer of an app, the user must have a verified Facebook developer account.
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 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.
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.
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.
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.
We also enable you to restrict some of your API calls to come from a set of white-listed servers. Learn more in our login security documentation.
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.
We've provided information on IP whitelists and User Agent strings for Facebook's crawlers in our Facebook Crawler guide.
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.
If you're connecting to Facebook's servers your client must:
sha256WithRSAEncryptionas 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.