Facebook’s New Security Changes for Developer Apps (WordPress-ready)

Facebook rolled out important security changes that affect how developer apps handle credentials, access tokens, and user sessions. These updates tighten OAuth flows, improve app-level protections, and introduce controls to prevent token theft and session-fixation attacks. Below is a clear, developer-focused summary you can paste into a blog post or internal doc.

Summary & Timeline

Facebook gave developers 90 days from December 19, 2017 (deadline: March 19, 2018) to adopt these changes. The main themes:

App Security — protect app secrets and configure advanced settings.
Access Token Security — stop token leakage via redirect URIs and require secure token exchange.
User / Account Security — prevent session fixation and strengthen developer account protections.

1. App Security (what developers must do)

Facebook expects apps to actively secure their own secrets and endpoints.

Key items

Advanced Security Settings — enable the new settings in the App Dashboard (do this first).
Avoid hard-coded secrets — don’t store your app_id, app_secret, or redirect URIs as public static constants in source code or repositories.
App Secret Reset — Facebook added a reset option for app secrets — use it if a secret is compromised.
Server IP Whitelisting — restrict server-side endpoints to known IPs (e.g., your production servers) so only those servers can talk to sensitive endpoints.

2. Facebook Developer Account Security

Protect the human accounts that manage apps.

Two-Factor Authentication (2FA) — Facebook introduced 2FA (SMS-based OTP) for developer accounts. Require & enable 2FA for all developers with access to your apps.

3. Access Token & OAuth Security (protecting user tokens)

This is the largest set of changes — aimed at stopping token theft from redirect flows and misuse of tokens by rogue apps.

Problem

When a user signs into an app via Facebook, an access token is issued. If a malicious party tricks Facebook (or the user) into returning that token to a malicious redirect URI, the token can be stolen and abused.

Facebook’s fixes & best practices

Lock Down OAuth Settings
- Pre-register allowed redirect domains and subdomains in the FB App Dashboard (e.g., example.com, login.example.com). Facebook will only redirect to pre-registered domains.
Switch from response_type=token to response_type=code
- Old: response_type=token — immediate access token in redirect (riskier).
- New: response_type=code — Facebook returns an authorization code (short-lived) in the redirect. Your server redeems that code for an access token server-to-server, keeping the token off the browser/URL.
Authorization Code Flow (OAuth Authorization Code Grant)
- User authorizes → FB returns an authorization code to your registered redirect URI.
- Your server calls Facebook’s token endpoint with the code, app id, app secret, and original redirect URI to retrieve the actual access token. This exchange prevents exposure of the token in the browser.
App Secret Proof
- Instead of sending app_secret with every API call, Facebook expects an HMAC (SHA-256) computed over the access_token and app_secret: appsecret_proof = HMAC_SHA256(app_secret, access_token)
- Facebook validates that proof server-side to ensure calls using the token originate from holders of the correct app secret.
Keep App Secret Confidential
- Because the code-exchange and appsecret_proof depend on the app secret, store it securely on your server-side (never in client apps or public repos).

4. Token Validation (prevent token reuse/misuse)

Even with the new flows, you should validate tokens you receive.

Token Debugging Endpoint
- Use Facebook’s debug endpoint (e.g., graph.facebook.com/debug_token?input_token={token}&access_token={app_token}) to confirm a token’s metadata (which app it was issued to, user id, expiry).
- This lets your server verify: “Was this token actually issued for my app?” If the token belongs to another app (attacker), reject it.

Typical attack scenario

Malicious app WFM1 tricks user into login → receives token for WFM1 → uses that token to call your backend endpoints pretending to be the user.
Mitigation: call debug_token to ensure the app_id on the token equals your app id before accepting it.

5. Session Fixation & CSRF-style Login Attacks

Session Fixation / Login CSRF: If attackers can force a user to re-use or reuse a session id or craft a login link that binds attacker-controlled session data to a victim, they can hijack sessions.
Defenses:
- Use CSRF state parameters in OAuth flows (state parameter) and validate them on return.
- Keep the OAuth redirect flow server-side where possible.
- Implement secure, HttpOnly cookies for session tokens and rotate session identifiers after authentication.

6. Recommended Checklist for Developers

Enable Advanced Security Settings in FB App Dashboard.
Use response_type=code (authorization code flow) for OAuth logins.
Register and lock down redirect URIs and allowed domains in the dashboard.
Keep app_secret only on trusted servers, rotate/reset if suspected compromised.
Implement appsecret_proof for server-to-Facebook calls.
Validate inbound tokens using Facebook’s debug_token endpoint.
Enforce 2FA for developer accounts.
Use state parameter to prevent CSRF/session fixation attacks in OAuth flow.
Whitelist server IPs for sensitive endpoints (where possible).

7. Developer FAQs (short)

Q: Why move to code (auth code) instead of token in redirect?
A: The auth code prevents tokens from appearing in URLs or browser history; tokens are obtained via a secure server-to-server call.

Q: What if I have a mobile app?
A: For mobile, use platform-recommended secure flows (e.g., native SDKs, PKCE for public clients) and keep secrets off the device. If you must, use short-lived tokens and refresh tokens securely on your backend.

Q: Can I still use client-side flows?
A: Client-side flows are still supported for public clients, but server-side authorization code flow is strongly recommended for any server-backed apps.

8. Final Notes

These Facebook platform changes shift responsibility to developers to store secrets safely, lock down OAuth endpoints, and validate tokens before letting them access user data. Adopting the authorization code flow, using appsecret_proof, and strictly controlling redirect URIs will dramatically reduce common token-theft and session-hijacking attacks.