We provide a set of features that aim to make Facebook Platform application management more secure. All these features are available in the application settings in the App Dashboard.
When testing your apps, place them into Sandbox 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 Sandbox Mode, you cannot 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 in Insights. Administrators can also add or remove other users to 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 most of which are accessible through the current App Dashboard or
admin.setAppProperties() API. They can also see insights for the app.
Unlike Administrators however, they cannot:
Testers can only test the app in sandbox 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 sandbox mode. In live mode all users will have test access to the app. Note that a user does not have to be verified to be added as a tester to an app.
Users with Insights User role can only access Insights for that app. They cannot access the app in sandbox mode and do not have access to any developer 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 from attacks by ensuring that only developers using the company IP addresses can update the settings.
This whitelist can be set in the Advanced tab of your app settings in the App Dashboard. You can specify a comma-separated list of IP addresses or a range of IP addresses. For example 188.8.131.52, 184.108.40.206-67
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 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 UI or the associated API method. 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 your API calls to come from a set of white-listed servers. You can set this whitelist by going to the advanced section of your Developer settings in the App Dashboard and set the 'Server whitelist' field.
You can enter a comma separated list of ip addresses or ranges. For example 220.127.116.11, 18.104.22.168-67
A number of Platform services such as Social Plugins and the 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 Internet, during testing or for other security reasons.
To facilitate this, you should make exceptions in your security systems to allow Facebook to crawl these pages by adding the following IP ranges, accurate as of March 2013.
22.214.171.124/21 126.96.36.199/18 188.8.131.52/20 184.108.40.206/20 220.127.116.11/19 18.104.22.168/22 22.214.171.124/22 126.96.36.199/18 188.8.131.52/22 2401:db00::/32 2620:0:1c00::/40 2a03:2880::/32
Please note that these IP ranges can and do change regularly, so you should periodically run the following command to receive an updated list -
whois -h whois.radb.net -- '-i origin AS32934' | grep ^route
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 behaviour and once the system has verified your site as a good actor, the step will be removed automatically.