Meta and LinkedIn App Tokens: Leak Response Guide

A leaked Meta app secret or LinkedIn client secret lets an attacker act as your application, and a leaked page or system user token lets them post, message and read data as your brand. Marketing, social listening and customer messaging integrations hold these credentials, often outside the security team's view: in agency scripts, low-code tools, CI variables and .env files. This page explains which credentials Meta and LinkedIn issue, what each can reach, how long they live, how to revoke or rotate them, what GitHub secret scanning catches and how to check whether a token is still live. It is written for engineers and security teams who own social media integrations, and for incident responders handling a leak. For general SaaS token practice see the SaaS API Token Security Guide.

Key takeaways

The app secret is the master key. On Meta, the app secret mints app access tokens (the {app-id}|{app-secret} form is itself a valid token) and computes appsecret_proof; on LinkedIn, the client secret obtains and introspects tokens. Reset it first if it leaks.
Some tokens never expire. Meta system user tokens can be created as non-expiring, and Meta says system user tokens and some long-lived Marketing API tokens do not expire on time alone. Choose the 60 day expiring option.
LinkedIn rotation has an overlap window. Generating a new client secret moves the old one to Secondary Client Secret, so both work until you remove the secondary. Remove it as soon as the new secret is deployed.
Coverage is uneven. GitHub notifies Meta about leaked Facebook access tokens and can check their validity, but LinkedIn client secrets get no partner notification; only your own repository alerts and push protection catch them.
Introspection is your validity check. Meta's debug_token returns is_valid, scopes and expires_at; LinkedIn's introspectToken returns status of active, expired or revoked. Use them during triage and after revocation.

How identity and access work in Meta and LinkedIn apps

Credential	Platform	What it does	Lifetime (vendor docs)
App secret	Meta	Authenticates the app server-side; generates app access tokens; keys `appsecret_proof`	Until reset (App Dashboard, Basic, App Secret)
App access token	Meta	Reads and modifies app settings; server-to-server calls	Tied to the app secret
Client token	Meta	Identifies the app in native or desktop clients; embedded, so not secret	Not a secret by design
User access token	Meta	Acts on one person's data with their consent	Short-lived about one to two hours; long-lived about 60 days; Meta warns these may change
Page access token	Meta	Reads, writes and modifies Page data	Not stated on the page checked
System user access token	Meta	Automation on Business Manager assets (ads, Pages, Instagram, WhatsApp) without a person	Non-expiring, or 60 days with `set_token_expires_in_60_days=true`
Client ID and client secret	LinkedIn	Identify and authenticate the app; client ID is public	Until rotated in the Developer Portal
3-legged access token	LinkedIn	Acts for a member within granted scopes	60 days (`expires_in` 5184000)
Refresh token	LinkedIn	Renews member tokens	Programmatic refresh tokens only for a limited set of partners
2-legged access token	LinkedIn	Non-member APIs for approved apps (not Marketing APIs)	30 minutes (`expires_in` 1800)

Meta's security guidance is blunt: never include the app secret or an app access token in client code or in an app binary that can be decompiled. LinkedIn's guidance lists the same exposure points: native mobile apps, JavaScript or HTML, externally viewable configuration files, and log files or error messages. Both describe tokens as portable bearer credentials; Meta notes they can be stolen by malware on a user's computer or through interception.

Admin roles and privileged access

Meta app administrators: the app secret and the settings that protect it live in the app dashboard (Basic for the secret; Advanced for the Server IP Allow List, Update Settings IP Allow List and Require App Secret), so dashboard access is privileged access. Keep app roles to named staff, and treat agency access as third-party access.
Meta Business Manager and system users: system users are non-human identities for servers or software acting on assets owned or managed by a business. Meta's guidance is to use a person's own user token, not a system user, when the software acts for a real person managing an ad account, so actions stay attributable.
LinkedIn Developer Portal: the Auth tab holds the Client ID, the Primary Client Secret and any Secondary Client Secret. Whoever can open it can rotate, or copy, the secret.
Scope breadth is privilege: Meta system user tokens can carry scopes such as business_management, ads_management, pages_manage_posts and whatsapp_business_messaging. A token with business_management is effectively an administrative credential for the business.

See the NHI Ownership Guide for assigning owners to every app and system user.

Integrations, API tokens and service accounts

Require appsecret_proof: with Require App Secret enabled (App Settings, Advanced, Security), every Graph API call must carry an appsecret_proof, an HMAC-SHA256 of the access token keyed with the app secret. A stolen user or page token alone then fails against your app, because the attacker also needs the secret. Meta's Login Security page adds appsecret_time, with proofs expiring after 5 minutes.
Restrict by network: the Server IP Allow List limits the IP addresses that can make Graph API calls with your app secret; Meta notes user access tokens are not affected. Use it for server-to-server integrations with fixed egress addresses.
Prefer expiring system user tokens: generate them through POST /SYSTEM-USER-ID/access_tokens with set_token_expires_in_60_days=true, which Meta recommends and some businesses must use. Refresh within the 60 days with grant_type=fb_exchange_token; if the window passes, a new token must be generated.
Request minimal scopes on LinkedIn: members must accept all requested scopes together, and requesting a different scope set invalidates earlier access tokens. Design scopes once and keep them narrow.
Keep tokens out of .env files in repositories and on web servers: the 230 Million AWS Cloud Environments campaign harvested publicly served .env files that held, among other things, social media credentials. See the Environment Variables and .env Files guide.

Choosing the credential for an integration

Use case	Use	Avoid	Why
Scheduled posting or ad automation for your own business assets	Meta system user with an expiring token and minimal scopes	A marketer's long-lived user token	Survives staff changes, owned by the business, and can be revoked without touching a person's account
Software acting for a named person who manages an ad account	That person's user access token via Facebook Login	System user token	Meta advises user tokens so actions stay linked to the individual
Server reading app settings or insights	App access token generated server-side, with Server IP Allow List	App secret in client code	Keeps the secret on servers with fixed egress
LinkedIn posting for members	3-legged tokens with the fewest scopes	Sharing one member's token across tools	Each tool's access can be withdrawn separately
LinkedIn non-member APIs (where approved)	2-legged client credentials tokens requested per run	Caching tokens beyond the run	30 minute tokens limit replay after theft

Small teams with one social integration can manage this with a register and a calendar reminder for refreshes. Larger organisations with agencies, regional brands and many Pages should treat each agency and region as a separate system user or app, so one leak does not expose every brand, and review access quarterly.

Logging and detection

Secret (GitHub name)	Secret type	Partner	User alert	Push protection	Validity check
Facebook Access Token	`facebook_access_token`	Yes	Yes	Yes	Yes
LinkedIn Client Secret	`linkedin_client_secret`	No	Yes	Yes	No

GitHub's pattern list (checked 28 October 2026) has no separate rows for Meta app secrets, Instagram tokens or LinkedIn access tokens, so add custom patterns or a second scanner for those. Validity checks for Facebook access tokens let you prioritise live tokens in the alert queue.

Neither platform's pages checked describe a customer-facing audit log of token use. Detection therefore relies on three sources:

Token introspection: Meta GET /debug_token?input_token=... (called with an app access token or an app developer's user token) returns is_valid, issued_at, expires_at, data_access_expires_at, scopes, granular_scopes and user_id. LinkedIn POST https://www.linkedin.com/oauth/v2/introspectToken with client_id, client_secret and token returns active, status, created_at, expires_at, scope and auth_type (2L, 3L or Enterprise_User).
Your own API gateway or application logs: outbound calls to graph.facebook.com and api.linkedin.com from your servers form the baseline; calls you did not make show up only as effects on the platform.
Platform-side effects: unexpected Page posts, ad campaigns, messages, app setting changes or new admins. Meta states it runs automated systems to detect stolen-token abuse; do not rely on them alone.

Meta also advises that apps not using its SDKs check token validity manually at least daily, because tokens can expire early for security reasons. Build that check into the integration so a revoked token raises an alert rather than a silent failure.

Leak response, step by step

Identify what leaked. App secret, app access token (app-id|secret form contains the secret), page token, system user token, user token, LinkedIn client secret or member token. Run introspection to confirm validity and scopes before you revoke, and record the output.
Meta app secret: reset it at App Dashboard, Basic, App Secret, then update every server that uses it. Turn on Require App Secret if it was off: Graph API calls then need an appsecret_proof computed with the secret, so stolen user or page tokens cannot be used on their own.
Meta system user token: revoke with GET oauth/revoke passing client_id, client_secret, revoke_token and access_token; Meta states revocation is immediate. For a planned rotation use refresh, deploy, then revoke.
LinkedIn client secret: in the Developer Portal Auth tab choose Generate a New Client Secret and confirm. Deploy the new Primary Client Secret, test, then remove the Secondary Client Secret immediately; until you do, the leaked secret still works.
LinkedIn member tokens: no revocation endpoint is documented on the pages checked. Members can revoke the app's permission grant; otherwise rely on the 60 day expiry, rotate the client secret, and confirm status with introspectToken.
Review effects. Check Pages, ad accounts, Instagram and WhatsApp Business assets for changes since the exposure, and review app roles and Business Manager users for additions.
Clean the source and close the gap. Remove the secret from history and logs, then add the missing control: secret manager storage, IP allow list or appsecret_proof.

Hardening baseline

Control	Meta	LinkedIn
Bind tokens to the secret	Require App Secret with `appsecret_proof`	Not described; protect the client secret
Network restriction	Server IP Allow List; Update Settings IP Allow List	Not described on pages checked
Short lifetimes	Expiring 60 day system user tokens; short-lived user tokens where possible	2-legged tokens last 30 minutes; member tokens 60 days
Rotation	Reset app secret; refresh-deploy-revoke for system user tokens	Primary and secondary client secret rotation
Least privilege	Minimal scopes per system user; separate system users per integration	Minimal scopes; separate apps per product

Framework mapping

Framework	Reference	Why it applies
MITRE ATT&CK	T1528 Steal Application Access Token; T1550.001 Application Access Token; T1552.001 Credentials In Files	Theft and replay of app tokens; secrets in files
NIST SP 800-53 Rev. 5	IA-5, IA-5(7), AC-6, AU-6	Authenticator management, no embedded static authenticators, least privilege, review of activity
NIST CSF 2.0	PR.AA-01, DE.CM-03	Credential management and monitoring

Common misconfigurations

Non-expiring system user tokens in agency tools: a token shared with an agency years ago keeps working after the contract ends. Use expiring tokens and one system user per agency.
Leaving the LinkedIn secondary secret active: rotation that stops at Generate a New Client Secret leaves the leaked secret valid as the secondary.
App secret in a mobile or web client: both vendors forbid it, yet it recurs in quick prototypes; anyone can extract it and mint app tokens.
Require App Secret off: stolen page and user tokens then work from any server.
Treating the client token or client ID as the leak: these are public by design; the real exposure is the secret or a bearer token, so triage on those.
Personal user tokens for automation: a long-lived user token from a marketer's account fails when they leave, or keeps their full access in a script nobody owns.

Practitioner checklist

Inventory every Meta app, system user and LinkedIn app, with an owner, the scopes granted and where secrets are stored.
Enable Require App Secret and the Server IP Allow List for server-side Meta integrations.
Replace non-expiring system user tokens with 60 day expiring tokens and automate the refresh.
Rotate LinkedIn client secrets with the primary and secondary process and remove the secondary the same day.
Add custom secret scanning patterns for Meta app secrets and LinkedIn tokens that GitHub does not cover.
Schedule daily introspection of production tokens and alert on is_valid false or status revoked.
Review app roles, Business Manager users and agency access each quarter.
Track metrics: non-expiring tokens in use, time from leak alert to revocation, integrations without an owner, and apps without Require App Secret.

Social platform app tokens: Contain leaked Meta and LinkedIn app secrets and tokens