TL;DR: A misconfigured Salesforce setting can expose sensitive files through public links, and Obsidian Security says a majority of organisations still have the feature misconfigured despite the risk being flagged in 2024. The pattern shows that SaaS sharing controls fail when visibility, ownership, and remediation discipline are weak, not just when access is too broad.
At a glance
What this is: This analysis shows that Salesforce public link misconfiguration can expose sensitive files outside the organisation when sharing controls are enabled too broadly and monitored too weakly.
Why it matters: IAM and SaaS security teams need to treat file sharing as a governed access pathway, because misconfiguration, user discretion, and poor visibility can turn ordinary collaboration features into data exposure risks.
Context
Salesforce public links are a SaaS sharing control, not just a convenience feature. When that control is misconfigured, files can become accessible to external parties without a clear review path for administrators or security teams.
The governance gap is familiar across SaaS: users can create sharing pathways faster than teams can inventory them, validate them, and remove them. In this article, Obsidian Security argues that public-link exposure persists because ownership, visibility, and remediation are not aligned.
That makes the issue relevant to both human IAM and NHI-adjacent SaaS governance, because the risk sits at the boundary between access policy, user behaviour, and lifecycle enforcement.
Key questions
Q: What is the main failure mode when Salesforce public links expose files externally?
A: The failure mode is uncontrolled file sharing, where a legitimate collaboration feature creates public exposure without strong limits on who can share, how long the link stays active, or whether the file still needs to be public. The risk grows when admins cannot quickly inventory or revoke those links.
Q: Why do Salesforce public link misconfigurations create data exposure risk?
A: They create risk because external accessibility is tied to a user-facing setting rather than a tightly governed access workflow. If password protection, expiration, and privilege scoping are optional or inconsistently enforced, the organisation loses control of who can reach the file and for how long.
Q: What do security teams get wrong about SaaS file-sharing controls?
A: Teams often assume that enabling a sharing feature is enough, but the real issue is whether they can see, review, and remove every active exposure. Without ownership data, posture telemetry, and cleanup discipline, public links remain live long after their business purpose has ended.
Q: How should security teams control public file sharing in Salesforce?
A: Teams should treat public file sharing as a governed entitlement, not a convenience feature. Limit who can create links, require password protection and expiration, and review publicly shared files on a recurring schedule. The control must be enforced through policy and monitoring, because manual review alone will miss stale exposure.
Technical breakdown
How Salesforce public links expand the sharing attack surface
Public links convert an internal file into an externally reachable object. In practice, that means the security boundary is no longer just the Salesforce session or role model, but the specific content-sharing setting attached to the file. If password protection and expiration are optional, the control is only as strong as the user applying it. That is why the risk is governance-related as much as it is technical: the platform allows a legitimate workflow that can bypass the intended access boundary when misused or left too broad.
Practical implication: treat public-link creation as a governed entitlement, not a casual user action.
Why visibility and posture rules matter in SaaS governance
SaaS misconfiguration becomes persistent risk when teams cannot see which files are publicly exposed, who shared them, and whether the exposure still serves a valid business need. Obsidian Security’s article describes supporting evidence such as file count by sharer and file expiration status, which are useful because they tie the finding to accountable users and time-bound exposure. This is less about one bad setting and more about missing operational telemetry across the collaboration layer.
Practical implication: monitor sharing telemetry and ownership metadata as part of routine SaaS posture review.
Why remediation has to combine policy enforcement and cleanup
A SaaS exposure issue is only partly fixed by changing the default. Existing public links remain active until they are explicitly removed, and optional protections can still be disabled by the user in some flows. That means remediation needs two layers: enforce safer defaults for future sharing and actively retire already-exposed links. Without both, the organisation keeps accumulating exposed files even after the underlying policy is tightened.
Practical implication: pair configuration hardening with active cleanup of existing public links.
Threat narrative
Attacker objective: The objective is to obtain externally accessible sensitive Salesforce files through a link that bypasses normal internal access boundaries.
- Entry occurs when a user creates a Salesforce public link for a file that should have remained internal or restricted.
- Exposure persists when password protection or link expiration is absent, disabled, or not enforced consistently across users.
- Impact follows when external parties can retrieve sensitive content through a shareable link without the organisation noticing quickly enough.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Salesforce public-link exposure is a SaaS governance failure, not a single misclick. The security problem is that collaboration features are often deployed faster than the organisation can govern them. Once public sharing is available, the control boundary depends on visibility, user behaviour, and post-creation cleanup, all of which are uneven in many SaaS programmes. The practitioner implication is that file-sharing entitlements must be treated as an access lifecycle issue, not a one-time configuration task.
Public-link risk exposes a governance assumption that access will be noticed before it matters. That assumption is designed for stable, reviewable access patterns. It fails when a user can create an externally reachable file link instantly and leave it active without consistent expiration or approval discipline. The implication is that SaaS governance cannot rely on after-the-fact review alone when the exposure path is already public.
Visibility, ownership, and remediation are the decisive controls in this class of exposure. The article’s emphasis on file count by sharer and expiration summaries is important because it shows the operational questions teams actually need answered. Which users can create links, which files are still public, and which exposures have never been retired are the questions that define control maturity. The practitioner implication is that SaaS governance should prioritise account-level accountability over broad policy statements.
File sharing must be governed as a bounded entitlement with expiry and revocation semantics. That framing is useful because it aligns the control with how the risk actually behaves across SaaS applications. If the organisation cannot prove who may share, for how long, and under what restrictions, then the sharing feature is functionally open-ended. The practitioner implication is that public link governance belongs inside the broader access and lifecycle programme, not in a separate admin checklist.
Public-link exposure and third-party token abuse are different threat paths, but they point to the same SaaS blind spot. Both show that downstream access in SaaS environments can expand beyond the original intent of the control plane. The difference is whether exposure comes from a user-managed sharing setting or a delegated integration token, but the governance lesson is the same: SaaS access paths need continuous inventory, ownership, and retirement. The practitioner implication is to unify sharing, delegation, and integration oversight in one programme.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
What this signals
SaaS governance teams should stop treating external file sharing as a feature toggle and start treating it as an access pathway with an owner, an expiry, and a revocation requirement.
Sharing entitlement drift: the practical risk is not that one user shares one file, but that the organisation gradually loses track of who can create public links and which files remain exposed. That is why entitlement reviews, not just policy text, have to sit inside the file-sharing control model.
For practitioners
- Restrict public-link entitlement scope Limit the Content Deliveries and Public Link capability to only the users who truly need external file sharing, and review profile and permission set assignments for that privilege.
- Enforce password and expiry controls Require passwords on externally shared files and make link expiration part of the default sharing process so that public links do not remain open indefinitely.
- Review all currently public files Search for files already shared via public links, confirm whether each one still has a valid business need, and remove the link where exposure is unnecessary.
- Add posture rules for exposed links Use detection logic that flags publicly accessible files with no password requirement and prioritise remediation by user, file count, and expiration status.
Key takeaways
- Salesforce public links can turn a normal collaboration feature into an external exposure path when governance is weak.
- The article points to broad misconfiguration and operational blind spots, not just isolated user mistakes.
- The strongest controls are entitlement scoping, mandatory expiry and password protection, and active cleanup of already public files.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | External sharing paths in SaaS create third-party exposure risk when access is not tightly governed. |
| NHI-06 — Insecure Cloud Deployment Configurations | The article centres on a cloud SaaS configuration that exposes files publicly when set incorrectly. | |
| Recommendation — Review externally reachable sharing paths for third-party exposure and revoke unnecessary access paths. Harden cloud sharing defaults and verify public-link settings against approved access policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Public-link sharing depends on entitlement scope and authorization governance inside the SaaS app. |
| Recommendation — Tighten entitlements for public-link creation and recertify who can share externally. | ||
| CIS Controls v8 | CIS-5 — Account Management | Who can create and remove public links depends on account and permission management. |
| Recommendation — Constrain public sharing to approved accounts and remove stale sharing privileges. | ||
Key terms
- Public Link: A public link is a shareable URL that lets someone outside the organisation access a file or resource without logging in through the normal internal access path. In SaaS environments, it becomes a governance issue when it outlives the business need or bypasses expected security controls.
- SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.
- Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 29, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org