Authorization controls that govern what users can do with Salesforce objects and fields. CRUD governs create, read, update, and delete rights at the object level, while Field Level Security governs access to individual fields. In custom code, these checks must often be enforced manually when execution runs in system context.
What CRUD and FLS Actually Control in Salesforce
CRUD and Field Level Security are the core authorization layers that determine whether a user can create, view, edit, or delete an object record, and which individual fields are visible or editable on that record. They are not general authentication features; they are permission checks applied after a user already has access.
CRUD applies at the object level, so it answers questions like whether someone may create an Account or delete a Case. FLS applies at the field level, so it answers whether a user can see a salary field, edit an approval status, or read a sensitive note even when the record itself is accessible.
Why Both Layers Matter Together
These controls work as a pair because object access alone does not make every field safe to expose, and field restrictions alone do not prevent someone from acting on an entire record. A user may legitimately have access to a record but still need individual fields hidden to preserve confidentiality, integrity, or role separation.
In Salesforce, the combination is especially important because downstream sharing and record access can be broader than the data that should actually be usable. A design that ignores FLS can unintentionally expose sensitive business data, while a design that ignores CRUD can allow users to manipulate objects they should only be allowed to inspect.
How CRUD and FLS Behave in Custom Code
Standard UI enforcement is only part of the story. When Apex or other custom logic runs in system context, the platform may bypass the end user’s object and field permissions unless the code explicitly checks them. That means the developer, not the platform alone, must preserve the intended security boundary.
This matters most in automation, integration handlers, and service-layer code that reads or writes data on behalf of users. If code assumes the caller’s permissions are being enforced automatically, it can create a gap between what the user is allowed to do in the interface and what the application actually performs behind the scenes.
Common Failure Modes and Design Trade-offs
CRUD and FLS are easy to misapply because they can look redundant when record sharing, page layouts, and profile settings already seem strict. In practice, they answer different questions, and secure designs need both the platform configuration and the custom-code checks to align.
Another common mistake is treating a successful record query as proof that a field should be processed. A record can be accessible while certain fields remain restricted, so safe handling requires more than checking whether the object exists or whether the user reached the page.
Risk and Threat Considerations
When CRUD and FLS are missing or inconsistently enforced, the result is usually overexposure of data or unauthorized record changes rather than a complete platform compromise. The risk is highest in custom code, bulk processing, and integrations that run with elevated execution context, because those paths can bypass the user’s intended data boundaries.
Failure mechanism: Code that trusts system context too broadly, omits explicit object or field checks, or processes data after a permissive query can let users read restricted fields, modify objects they should not control, or infer sensitive values from application behaviour.
Impact: Sensitive customer, financial, or operational data can be exposed or altered, reporting can become unreliable, and downstream approvals or workflow decisions can be corrupted by data that should never have been available to the caller.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | CRUD and FLS enforce least-privilege data access at object and field scope |
| AC-3 — Access Enforcement | CRUD and FLS are access-enforcement checks for records and fields | |
| IA-5 — Authenticator Management | Custom-code permission checks depend on reliable identity and session handling | |
| Recommendation — Apply AC-6 to limit object actions and field access to only what each role requires. Use AC-3 to enforce object and field permissions consistently in every access path. Bind permission decisions to verified identities and managed credentials before permitting data operations. | ||
| OWASP ASVS | V8 — Authorization | CRUD and FLS are authorization controls governing object and field access |
| V15 — Secure Coding and Architecture | Custom code must explicitly preserve security boundaries when platform defaults are bypassed | |
| Recommendation — Verify that authorization rules cover both object-level actions and field-level data exposure. Implement permission checks in code paths that execute with elevated context. | ||
| ISO/IEC 27001:2022 | A.8.3 — Information access restriction | CRUD and FLS restrict who can access or modify information elements |
| Recommendation — Configure access restrictions so users only see and change authorised information. | ||
Practitioner Guidance
Governance implication: Treat CRUD and FLS as separate enforcement requirements in Salesforce design reviews, especially for Apex, triggers, batch jobs, and service integrations. The key practitioner judgement is not whether the page looks secure, but whether every data-access path enforces the same object and field boundaries the business expects.
Practitioner takeaway: If code can run outside the user’s native permission context, security must be asserted deliberately at the object and field level, not assumed from the surrounding application flow.
