Salesforce file attachments can still be read in plaintext by administrators, integrated apps with file access, and anyone holding a public link. Role hierarchy does not reliably protect file contents, and public links can be forwarded without strong recipient controls. For PHI, cardholder data, and other sensitive records, that breaks the confidentiality assumptions teams often make about standard platform controls.
Why This Matters for Security Teams
Salesforce file attachments often sit outside the mental model security teams apply to role-based access. A record may look tightly controlled while the attached file can still be exposed through admin access, embedded integrations, or a public link. That gap matters in regulated workflows because confidentiality is judged by the data itself, not only by who can see the parent object. NIST guidance in the NIST Cybersecurity Framework 2.0 reinforces that data protection has to follow the asset across its lifecycle.
The practical risk is that many teams treat sharing settings as a complete control when they are only one layer. If a file contains PHI, cardholder data, legal evidence, or customer identity records, downstream access paths can defeat the intended restriction even when role hierarchy is correctly configured. This is especially important in audit-sensitive processes where a single disclosure can create both security and compliance impact.
In practice, many security teams encounter file exposure only after a workflow has already been built around assumptions that the platform does not actually enforce.
How It Works in Practice
Salesforce files can inherit visibility from multiple mechanisms, and that is where the confusion starts. The parent record may be limited by role, sharing rule, or queue membership, but the file itself can be reachable through separate permission paths. Administrators, users with broad file privileges, integrated applications, and recipients of a shared link may all gain access without needing the same record-level visibility.
For regulated workflows, the main issue is that access control is not always equivalent to content control. A user can be blocked from opening a case or opportunity and still read an attachment if the file was shared more broadly, synced into another system, or exported into a mailbox or document store. NIST SP 800-53 Rev 5 Security and Privacy Controls emphasizes the need for granular control over access, auditability, and information flow, which is exactly where file-centric workflows need extra attention.
- Classify the file, not just the object it is attached to.
- Review who can view, download, share, or administer files separately from record access.
- Treat public links as transferable access, not recipient-bound access.
- Check how connected apps and automation interact with file permissions.
- Log and review file access events alongside record access events.
Non-human identities often widen this exposure. Integration users, service accounts, and automation tools may need file access to operate, but their permissions are frequently broader than intended or poorly reviewed. The OWASP Non-Human Identity Top 10 is relevant here because machine identities often inherit persistent access paths that bypass human approval flows. These controls tend to break down when files are copied into secondary systems, because the original Salesforce permission model no longer governs the new storage location.
Common Variations and Edge Cases
Tighter file controls often increase operational overhead, requiring organisations to balance confidentiality against user friction and integration complexity. That tradeoff is especially visible when teams rely on external collaboration, case management portals, or automated document generation.
Best practice is evolving for environments that mix regulated data with fast-moving business workflows. Some teams attempt to solve the problem with role redesign alone, but that rarely closes the gap because file sharing, admin visibility, and downstream exports are separate control planes. Others rely on link expiration or download restrictions, but those measures reduce exposure rather than eliminate it.
There is no universal standard for this yet, but the safest pattern is to apply data-loss thinking to file attachments: minimize attachment use for sensitive records, constrain who can create shareable links, and enforce classification and retention controls before content enters the CRM. Where automation is required, non-human identities should be limited to the smallest file scope possible and reviewed with the same discipline as privileged human access. In regulated settings, the deciding question is often not whether a role can open the parent record, but whether the attachment can leave the intended trust boundary without detection.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | File attachments need data protection beyond record-level sharing. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central when admins and apps can read attachments. |
| OWASP Non-Human Identity Top 10 | NHI-08 | Service accounts and integrations can widen attachment exposure. |
Apply data protection controls to files wherever they move, not just to the parent record.
