Because system context bypasses the automatic authorization checks that user context normally enforces. Custom Apex, triggers, asynchronous code, web services, and some Lightning patterns can access objects and fields without built in guardrails. Teams should explicitly call the relevant isAccessible, isCreateable, isUpdateable, or isDeletable methods, or use Lightning Data Service where it fits.
Why Salesforce code paths need explicit CRUD and FLS checks
Salesforce does not apply the same authorization behavior in every execution context. In user context, the platform can enforce object- and field-level access automatically; in system context, that protection may not happen unless the code checks it itself. That is why Apex, triggers, async jobs, and some integration or Lightning patterns must validate CRUD and FLS before reading or changing data.
That distinction matters because the security question is not “can the code run,” but “whose permissions are being applied when it runs.” When execution shifts from the current user to elevated platform context, the code can bypass the guardrails a user would normally depend on, so access decisions become a developer responsibility rather than a platform default.
Where the authorization boundary changes
The important split is between code that inherits user permissions and code that runs with broader authority. Standard UI interactions often respect the user’s visibility and edit rights, but custom logic may not. If a trigger, batch job, queueable, web service, or controller can touch records directly, it may also reach fields the user cannot see or modify unless the code explicitly asks the platform to enforce those limits.
That is why Salesforce developers often use the object and field permission methods before proceeding with a data operation. For user-facing reads and writes, Lightning Data Service can reduce the need to hand-roll checks because it is designed to respect the platform’s access model. For lower-level code paths, the safer pattern is to treat CRUD and FLS as part of the business rule, not as an optional extra.
This is also where third-party guidance on web and API authorization is useful. The same class of failure appears when a system trusts runtime context too much and assumes the platform will block unsafe access for it, which is why broader application-security references such as the OWASP Top 10 remain relevant to Salesforce application design.
What breaks when teams assume the platform will check for them
The usual failure mode is privilege leakage through a code path that was written for functionality first and permissions second. A developer may correctly test a page or component in a friendly user scenario, then later discover that a trigger, batch process, or integration can expose hidden fields, update restricted objects, or delete records the initiating user could not normally affect. That gap becomes more serious when the same code path is reused across many users, tenants, or integrations.
In practice, the risk is not limited to accidental overexposure. A malicious or compromised integration, a poorly scoped connected app, or an internal user who can influence an elevated code path can abuse those missing checks to read more data than intended or change records outside their role. Salesforce security therefore depends on the combination of platform controls and explicit application logic, especially where the runtime context changes.
For Salesforce teams that build beyond the standard UI, API-oriented controls also matter. The permission boundary problem is closely aligned with OWASP API Security Top 10 concerns such as broken authorization, because the core issue is still whether each request is evaluated against the right access rule.
What good practice looks like in Salesforce code
Good practice starts with deciding whether the current code path should honor the user’s access or intentionally operate with elevated authority. If the path is user-driven, check object permissions before DML and field permissions before reading or writing sensitive fields. If the path is privileged by design, keep the elevated scope narrow and document why that exception exists.
What to verify: confirm that each sensitive read, create, update, delete, or field access point has an explicit permission decision, especially in code that can run outside the standard user interface. Pay particular attention to triggers, async jobs, web services, and reusable helper methods, because those are the paths most likely to be invoked from multiple contexts.
Decision rule: if the code can run in system context and touches user-controlled data, do not assume the platform will enforce least privilege for you. Add the check at the point of use, or choose a framework such as Lightning Data Service when it can carry the access rules for you. The Salesforce-specific patterns are well illustrated in NHIMG’s SalesBleed Salesforce Agentforce 2026 analysis, which shows how a privileged Salesforce path can be turned into data exfiltration when access boundaries are weak.
Practitioner takeaway: Treat CRUD and FLS as explicit security controls in every non-UI Salesforce execution path, because once code runs with broader authority, access enforcement is no longer automatic.
Risk and Threat Considerations
The main risk is unintended privilege expansion, where business logic executes successfully but with more authority than the initiating user should have. That creates confidentiality risk for hidden fields, integrity risk for record changes, and audit risk when the code path cannot prove it respected the intended access model.
Failure mechanism: system context or similarly elevated execution bypasses the user-level checks that would otherwise block object or field access, so any missing CRUD or FLS validation becomes a direct access-control gap.
Impact: restricted data can be read, modified, or deleted through code that appears legitimate, and a compromised integration or overbroad automation can turn that same gap into a scalable exfiltration or tampering path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Salesforce CRUD and FLS are authorization checks on data access. |
| V16 — Security Logging and Error Handling | Permission failures and elevated-context actions should be visible and auditable. | |
| Recommendation — Apply V8 checks to enforce object and field permissions before each sensitive operation. Log denied access and privileged data operations so missing checks are detectable. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | System-context code can exceed the initiating user's permissions without explicit controls. |
| IA-5 — Authenticator Management | Salesforce access paths often depend on credentials, tokens, or connected-app secrets. | |
| Recommendation — Limit execution paths so code only receives the access needed for its task. Manage and rotate credentials used by integrations that exercise privileged code paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions and Authorizations | The question is about enforcing object and field access in application code. |
| Recommendation — Verify each code path enforces permissions before data is read or changed. | ||
Practitioner Guidance
What to prioritise: review every code path that can run outside the standard UI first, because that is where developers most often overestimate platform enforcement. Then separate read checks from write checks, since field visibility and record mutability are not the same decision.
Common mistake: relying on one safe-looking component to protect an entire workflow. In Salesforce, a secure front-end does not automatically make a trigger, async process, or service layer safe.
What good looks like: sensitive operations fail closed when permission data is missing, and the code path can show exactly why an access decision was allowed. That is the point at which Salesforce security becomes auditable rather than assumed.
Practitioner takeaway: If the execution context can change, the access check must live with the operation, not only with the screen that started it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
