What breaks when users can approve Salesforce connected apps without review?

Where approval without review turns a consent flow into an access-control failure

When users can approve Salesforce connected apps on their own, the control stops behaving like governance and starts behaving like delegation with very weak oversight. A consent click can create standing access, token issuance, or cross-cloud trust that outlives the moment of approval, so the real question is who is allowed to create durable integration paths, not who can click “allow.”

That is why connected-app approval belongs in the same control family as access request, entitlement change, and privileged integration setup. When the approval process is loose, the environment can accumulate hidden trust relationships that are hard to inventory, harder to review, and easy to misuse later.

For practitioners, the important distinction is between convenience consent and governed authorisation. If the app can read CRM records, offline tokens, or downstream SaaS data, the approval is not a lightweight productivity action, it is a security decision that changes blast radius.

Why malicious OAuth grants are so effective

Malicious connected apps work because they can appear routine while granting durable access behind the scenes. Once a user or admin approves the integration, the app may receive scopes, refresh capability, and a trust relationship that bypasses many of the normal signals defenders use for interactive logins.

In practice, that makes the approval path attractive to attackers who want low-friction persistence. They do not need to defeat the password policy if they can persuade a user to authorise an app that is already trusted by the platform and by adjacent business workflows.

Because Salesforce is often connected to ticketing, marketing, support, and data export tooling, one bad grant can become a lateral movement path across SaaS environments. That is why ShinyHunters Salesforce data theft campaign 2025 and Salesloft OAuth token breach are useful reminders that the approval event itself can be the point where durable access is created.

What governance has to catch before the grant becomes normalised

Once user approval is allowed, the failure mode is not only unauthorised access, it is normalisation. Repeated approvals teach the organisation to treat third-party access as routine, which makes it harder to spot unusual scopes, third-party risk, and exceptions that should have required review.

That is why teams need explicit ownership for connected-app governance, not just IAM configuration. The review should ask whether the app is approved for the business function, whether its scopes are proportionate, whether the token lifetime is bounded, and whether the vendor relationship is understood well enough to survive compromise.

A practical control point is access certification. If app approvals are never revisited, the environment will keep stale integrations long after the original business need has expired. A governed review process, such as Access Reviews and Certification Guide, helps teams treat these approvals as revocable entitlements rather than permanent convenience.

The broader operating model also matters. IAM and IGA Basics is the better lens when you need to decide who may approve, under what policy, and how those approvals are recertified.

Risk and Threat Considerations

Unreviewed connected-app approval creates a high-value abuse path because it combines user trust, OAuth delegation, and SaaS-to-SaaS connectivity. The risk is not limited to one Salesforce tenant, because the resulting token or grant may expose CRM data, downstream APIs, and other cloud services that trust the same integration chain.

Failure mechanism: An attacker persuades a user or over-permissioned approver to authorise a malicious or compromised app, then uses the issued grant or token to read data, export records, or pivot into connected services without needing another interactive login.

Impact: Organisations can lose confidentiality, create persistent access paths that survive password resets, and miss the compromise because the activity looks like normal business authorisation rather than a malicious login event.

Practitioner Guidance

What to prioritise: Treat connected-app approval as an entitlement change, not a convenience setting. The highest-risk cases are apps with offline access, broad data scopes, export capability, or any path into production CRM records.

What to verify: Confirm who can approve apps, whether approvals are admin-only for sensitive scopes, and whether every approved app has an owner, a business purpose, and a defined review date. If you cannot name those three things, the grant is already too loose.

Decision rule: If the app can obtain persistent tokens or touch customer data, require pre-approval and periodic recertification. If it only supports low-risk productivity functions, still constrain scopes and monitor for scope creep rather than assuming user consent is harmless.

Practitioner takeaway: The governance boundary is the control that breaks first, so the objective is to make every connected-app approval revocable, reviewable, and proportionate to the data it can reach.

Related resources from NHI Mgmt Group

• What breaks when AI-generated mobile apps are shipped without security review?
• What breaks when employees can connect SaaS apps without security review?
• What breaks when downstream apps let users add a new SSO method without re-verification?
• What breaks when Salesforce connected apps share one integration user?