By NHI Mgmt Group Editorial TeamPublished 2025-04-29Domain: Governance & RiskSource: Obsidian Security

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 examines how Salesforce public link settings can expose files outside the organisation when sharing controls are misconfigured.

Why it matters: It matters because SaaS sharing misconfigurations create non-human identity governance gaps that IAM and security teams often do not see until data is already exposed.

By the numbers:

👉 Read Obsidian Security's analysis of Salesforce public link misconfiguration


Context

Salesforce public links are a simple sharing feature with an outsized governance problem: they can turn controlled files into externally reachable assets if the setting is left too open. For IAM and NHI practitioners, the issue is not just user behaviour, but the combination of privilege, policy, and weak visibility across SaaS collaboration paths.

The article also fits a broader pattern in SaaS security, where teams know a control exists but still struggle to inventory where it is enabled, who can use it, and whether the exposure is intentional. That is typical of NHI governance failures, where access is distributed across applications and identities that do not sit neatly inside traditional account review processes.


Key questions

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.

Q: Why do SaaS public links create IAM risk?

A: Public links create IAM risk because they bypass normal account-based access once the URL exists. The organisation must then govern the link lifecycle, not only the user identity that created it. Without review, a temporary share becomes persistent external access that is hard to track and harder to revoke.

Q: What is the difference between public link control and standard access review?

A: Standard access review checks who holds permissions inside the system. Public link control checks whether the data itself has become externally reachable through a shareable URL. Both matter, but public link control is broader because it covers access paths that do not rely on an active internal session.

Q: When should organisations treat a file share as a security incident?

A: Organisations should escalate any unexpected public link to a security incident when the file contains sensitive data, the share has no business owner, or the link lacks an expiry date. The decision should be based on exposure scope and persistence, not on whether the sharing was accidental.


Technical breakdown

How Salesforce public links create exposure paths

Salesforce public links allow files to be shared through externally reachable URLs rather than tightly scoped internal access. The risk appears when the feature is globally enabled or available to too many users, because the security boundary shifts from identity-based access to link possession. If password protection and expiration are optional, the link itself becomes a standing access path. That is a classic governance failure for SaaS, where convenience features outrun control design and the organisation loses track of what is publicly reachable.

Practical implication: Treat public link generation as an access pathway that must be explicitly authorised, logged, and time-limited.

Why visibility gaps turn a setting into a data leak

The control problem is not only exposure, but discovery. Security teams often cannot easily tell which files are public, which users created the links, or whether the files still need to remain shared. That makes remediation slow and inconsistent. In NHI terms, the exposure behaves like unmanaged credential use: once a share link exists, the organisation needs inventory, context, and expiry discipline to prevent long-lived access from persisting unnoticed.

Practical implication: Build continuous discovery for public-sharing settings and publicly reachable files across SaaS platforms.

Why posture rules matter more than one-time cleanups

A posture rule gives security teams a repeatable way to detect at-risk files, surface supporting evidence, and prioritise cleanup. That matters because a manual search for public links does not scale across large collaboration estates. The operational value is in summarising share counts, expiration states, and the users driving exposure so that remediation can be targeted rather than guessed. In practice, posture management closes the loop between policy and actual sharing behaviour.

Practical implication: Use automated posture controls to track exposure, prioritise remediation, and verify that remediation stays in place.


Threat narrative

Attacker objective: The attacker objective is to access sensitive Salesforce files through an externally reachable link without needing to compromise the underlying account.

  1. Entry occurs when a user creates or inherits permission to generate a Salesforce public link for a file that should remain restricted.
  2. Escalation happens when the link is left without password protection or expiration, turning a temporary share into persistent external access.
  3. Impact follows when outside individuals or groups retrieve confidential files through the public URL, bypassing normal internal access controls.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Salesforce public links are an NHI governance problem, not just a SaaS settings issue. The exposure begins as configuration, but it behaves like identity sprawl once the link is shared outside the organisation. Security teams need to treat share links as externally usable access artefacts that require lifecycle management, not one-off cleanup. The practical conclusion is that public sharing must sit inside identity governance, not beside it.

The real failure is the absence of continuous entitlement visibility. When teams do not know which files are public, who created them, or whether the exposure is still needed, remediation becomes reactive and incomplete. That is the same structural weakness seen in other non-human identity problems: access persists because no one owns the review loop. Practitioners should assume the current state is broader than any manual audit suggests.

Public-link controls should be evaluated as a blast-radius limiter. Passwords, expirations, and user scoping do not eliminate the need for external sharing, but they do reduce the duration and reach of accidental exposure. The key question is whether the organisation can prove that every externally reachable file is intentional, time-bound, and reviewable. That is the standard teams should adopt.

At scale, SaaS misconfiguration becomes a control-plane issue. Once a platform has many users, many files, and many sharing paths, the challenge is no longer educating users alone. It is building policy, detection, and remediation that converge on the same outcome. The practical conclusion is to govern public sharing as a recurring control, not a periodic project.

From our research:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
  • That visibility gap is why teams should pair SaaS sharing controls with lifecycle governance, as outlined in the NHI Lifecycle Management Guide.

What this signals

Public-link exposure should be treated as a recurring NHI control failure, not a one-time configuration issue. Once external sharing exists, the governance problem becomes lifecycle management. Teams need a repeatable process for discovery, approval, revocation, and verification across SaaS applications, not only in Salesforce. That is the difference between temporary cleanup and durable risk reduction.

With 72% of organisations reporting or suspecting an NHI breach in recent research, exposed sharing paths are part of a much wider identity surface. The implication for programme owners is that SaaS file sharing, OAuth-connected apps, and delegated access should be monitored as one connected exposure plane, not separate tools and tickets. The appropriate response is cross-platform entitlement inventory with clear ownership.

Runtime visibility is the next control gap teams need to close. Public links are easy to create and hard to track at scale, which makes the problem similar to unmanaged secret distribution. Security programmes should align detection, evidence capture, and revocation workflows so that public sharing can be reviewed in the same way as other high-risk non-human access paths.


For practitioners

  • Restrict public link creation to named business roles Limit the Content Deliveries and Public Links feature to only the users who genuinely need external file sharing, and review profiles and permission sets for scope creep.
  • Require password protection and expiration by policy Make password protection and link expiration the default for externally shared files, then verify that users cannot bypass those settings for sensitive content.
  • Inventory all public files and remove stale links Search for publicly shared files, identify links with no expiration, and delete anything that no longer has a clear business justification.
  • Automate posture detection for public sharing Use posture rules to surface file count by sharer, expiration state, and unsupported public links so remediation can scale across the SaaS estate.

Key takeaways

  • Salesforce public links can turn ordinary collaboration settings into externally reachable access paths when governance is weak.
  • The core problem is not just misconfiguration, but the lack of continuous visibility into who can share, what is public, and whether exposure is still justified.
  • Teams should respond with scoped permissions, mandatory expiry and password controls, and automated posture detection for stale shares.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Public link exposure reflects weak lifecycle control over non-human access paths.
NIST CSF 2.0PR.AC-4Least-privilege scoping applies directly to who can create public sharing links.
NIST AI RMFAI and automation workflows can amplify exposed SaaS content if governance is weak.

Map link-creation rights to least-privilege access and review them at each entitlement cycle.


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.
  • Posture Rule: A posture rule is a policy-based detection control that flags risky configuration states and unsupported access patterns. For NHI and SaaS governance, it helps teams identify exposure, prioritise remediation, and verify that controls remain effective after changes.
  • SaaS Misconfiguration: A SaaS misconfiguration is an application setting that expands access, visibility, or sharing beyond what the organisation intended. It is often caused by default permissions, inconsistent admin review, or user-driven features that were never tightly constrained.
  • Identity Blast Radius: Identity blast radius is the amount of data, systems, or users that can be reached once an identity or access path is compromised or misused. For shared files and links, it measures how far a single mistake can spread beyond the original intended audience.

Deepen your knowledge

Salesforce public-link governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building repeatable controls for SaaS sharing risk, this is a practical place to start.

This post draws on content published by Obsidian Security: Salesforce Misconfiguration Continues to Expose Links to the Public. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-04-29.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org