The Salesforce Security Model: CRUD, FLS, and Sharing
By the end of this lesson, you'll be able to:
- Explain the three layers of the Salesforce security model: CRUD, FLS, and sharing
- Understand how Lightning Data Service enforces all three automatically
- Recognize why a raw SOQL query in Apex does not enforce these by default
Prerequisites: Module 11: "Internationalization Considerations"
The Three Layers
- CRUD (object-level) — can this user Create, Read, Update, or Delete records of this object type at all? A user without Read access to Opportunity shouldn't see any Opportunity data, full stop.
- FLS (field-level security) — even if a user can read an object, can they see this specific field? A Sales rep might see an Account's Name but not a custom
Credit_Score__cfield. - Sharing (record-level) — of the records this user could theoretically access, which specific ones can they actually see, based on org-wide defaults, role hierarchy, and sharing rules?
All three are independent, stacked checks — passing one says nothing about the others.
How LDS Enforces All Three Automatically
Module 6 noted that Lightning Data Service automatically enforces field-level security and sharing. That's genuinely all three layers — CRUD, FLS, and sharing — handled for free, with zero developer effort, whenever getRecord, createRecord, or a base record component is used.
WITH SECURITY_ENFORCED and stripInaccessible
List<Account> accounts = [SELECT Id, Name, Industry FROM Account WITH SECURITY_ENFORCED];A raw SOQL query in Apex does not enforce CRUD/FLS automatically — WITH SECURITY_ENFORCED (Module 7) is what makes Apex throw if the running user lacks access to any queried field. For data assembled into a wrapper class (Module 7) rather than returned directly from a query, Security.stripInaccessible() is the equivalent tool — it strips out fields the user can't access from an already-fetched result.
Why This Matters in Real Projects
A component that queries data insecurely can leak fields or entire records a specific user was never meant to see — not a cosmetic bug, but a genuine, serious security defect. This is exactly why Module 6 and 7 emphasized LDS and WITH SECURITY_ENFORCED from the start, rather than treating security as an afterthought bolted on later.
Exercise
A SOQL query in an Apex method used by LWC omits WITH SECURITY_ENFORCED. Explain, as a comment, what real risk this introduces.
Show hint
Think about what a raw query does and doesn't check by default.
Exercise
Challenge: explain, as a comment, why passing CRUD and FLS checks does not guarantee a user can see a specific record.
Show hint
Recall the third, independent layer.
The Salesforce Security Model: CRUD, FLS, and Sharing Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
CRUD, FLS, and sharing are three distinct, stacked layers of access control — a component that skips enforcing all three can leak data the running user should never see.