From F8 2015, Jonathan Gross and Brent Dorman look at ways to increase the security of your Facebook Login integration.
This list below should be considered the absolute minimum that all apps using Facebook Login should implement. Other features will be unique to your app and you will need to always think about how to make your app as secure as possible. Apps that are not secure will lose the trust of their audience and people will stop using them.
The App Secret is used in some of the Login flows to generate access tokens and the Secret itself is intended to secure usage of your App to only those that are trusted. The secret can be used to easily create an App Access Token which can make API requests on behalf of any user of the app, which makes it extremely important that an App Secret is not compromised.
We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token. For this reason, if your 'App Type' under Advanced Settings in the App Dashboard is set to
Native/Desktop we assume that your native app contains the App Secret or an App Access Token in the binary, and we do not allow calls signed with an App Access Token to proceed. The API will behave as though no access token was provided.
If your App Secret is compromised, you should reset it immediately in the Basic Settings of your App Dashboard. When you start the reset process, you can specify a number of hours that the compromised secret will continue to work for when making requests, however anything sent from Facebook (such as signed requests) will use the new secret straight away, so you must adjust your code to expect it as soon as possible.
You can reduce your exposure to malware and spammers by requiring server-to-server calls to Facebook's API be signed with the
appsecret_proof parameter. This topic is covered in our Securing Graph API Calls documentation.
In some configurations, apps will reuse a long-term token across multiple clients. Don't do this. Instead use short-term tokens that are generated with the code flow, as described in our access token documentation.
To understand how this happens, imagine a native iOS app that wants to make API calls, but instead of doing it directly, communicates with a server owned by the same app and passes that server a token generated using the iOS SDK. The server would then use the token to make API calls.
The endpoint that the server uses to receive the token could be compromised and others could pass access tokens for completely different apps to it. This would be obviously insecure, but there is a way to protect against this - access tokens should never be assumed to be from the app that is using them, instead they should be checked using debugging endpoints.
Strict Mode keeps apps safe by preventing bad actors from hijacking your redirect. Enabaling Strict Mode is currently required for the Instagram API, and will soon be required for all apps.
Before turning on Strict Mode in the App Dashboard, ensure your current redirect traffic still works by taking the following actions in Facebook Login settings:
For apps with dynamic redirect URIs, use the state parameter to pass back the dynamic information to a limited number of redirect URIs. Then add each of the limited redirect URIs to the Valid OAuth redirect URIs list.
For apps with a limited number of redirect URIs, add each one to the Valid OAuth redirect URIs list.
After taking these actions, make sure to enable strict mode.
Strict Mode prevents hijacking of your redirect URIs by requiring an exact match from your Valid OAuth redirect URIs list. For example, if your list contains www.example.com, then Strict Mode won't allow www.example.com/token as a valid redirect. It also won't allow any extra query parameters not present in your Valid OAuth redirect URIs list.
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. Learn more in our access tokens documentation.
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.
The App Dashboard contains a number of additional settings which allow developers to shut down areas of attack that might otherwise lead to security issues:
Native/Desktopto protect against your app being decompiled and your app secret stolen.
Use HTTPS, instead of HTTP, as an internet protocol, because it uses encryption. HTTPS keeps transmitted data private and guards against eavesdropping attacks. It also prevents data from being tampered with during transmission by, for example, introducing advertisements or malicious code.