When testing your apps, place them into development mode. This hides your app entirely from all users who you have not authorized in the App Dashboard to see the app, for the roles described below. Please note that when your app is in development mode, you can't call any API calls on behalf of users who cannot see your app.
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. All ‘developers’ currently added to an app have these permissions so they will get the administrator permissions as we move to the new model. Administrators of apps should only add other users as administrators if they are fully trusted and must have full control of the app.
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:
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.