Salesforce Security Model

When to use

• Any Apex class that queries or writes data, especially @AuraEnabled, @InvocableMethod, @RestResource, global, or Visualforce controller entry points.
• Building or reviewing permission metadata (permissionsets/, permissionsetgroups/, object/field permissions).
• Dynamic SOQL/SOSL, Database.query, string-concatenated queries, lwc:dom="manual", innerHTML, redirects, HTTP callouts with credentials.
• Wave 2 of the vibe-force workflow: sf-security-reviewer reads this skill before reviewing a diff; vf-check analyzer enforces the machine-verifiable subset.
• Auditing the standing posture of a whole org rather than one change: skill sf-org-security-audit, which reuses the permission queries in references/permission-architecture.md.

API version 67.0 default-mode change (read this first)

config/vibe-force.defaults.json pins apiVersion 67.0. That version changed the Apex security defaults:

Consequences for vibe-force code: never rely on the default. Declare with sharing / inherited sharing / without sharing explicitly on every class with data access, and set an explicit access mode (WITH USER_MODE, WITH SYSTEM_MODE, as user, as system, AccessLevel.*) on every database operation so the code reads the same on any API version. Triggers cannot carry a sharing declaration: they always run without sharing, so delegate to a handler class (see skill sf-apex-development).

Security layer decision table

Object/field permissions and sharing are independent and can coexist; where they conflict, object-level and field-level permissions take precedence over sharing rules.

Core patterns

1. Query in user mode (default choice)

public with sharing class ExpenseSelector {
    public static List<Expense__c> recent(Integer rowLimit) {
        return [
            SELECT Id, Name, Amount__c, Client__c, Date__c
            FROM Expense__c
            WHERE Date__c = LAST_N_DAYS:30
            WITH USER_MODE
            ORDER BY Date__c DESC
            LIMIT :rowLimit
        ];
    }
}

WITH USER_MODE processes every clause including WHERE, supports polymorphic fields (Owner, Task.WhatId), reports all FLS errors, and exposes them through QueryException.getInaccessibleFields(). It is the only clause-based option at our target version: in API 67.0 and later a SOQL SELECT in Apex cannot use WITH SECURITY_ENFORCED at all. Legacy (pre-67.0) code that still carries WITH SECURITY_ENFORCED must be migrated to WITH USER_MODE when its class is raised to 67.0; that clause also reported only the first error, skipped the WHERE clause, ignored polymorphic fields, and was never allowed in AppExchange packages.

2. DML in user mode, with error introspection

public with sharing class ExpenseWriter {
    public static void save(List<Expense__c> expenses) {
        List<Database.SaveResult> results = Database.insert(expenses, false, AccessLevel.USER_MODE);
        for (Database.SaveResult r : results) {
            if (!r.isSuccess()) {
                for (Database.Error e : r.getErrors()) {
                    System.debug(LoggingLevel.WARN, e.getStatusCode() + ' on ' + e.getFields());
                }
            }
        }
    }
}

Statement form: insert as user expenses; / update as system expenses;. On a user-mode DmlException, getDmlFieldNames() returns the fields that failed FLS.

3. Graceful degradation with stripInaccessible

SObjectAccessDecision decision = Security.stripInaccessible(
    AccessType.READABLE,
    [SELECT Name, BudgetedCost, ActualCost FROM Campaign WITH SYSTEM_MODE]
);
if (decision.getRemovedFields().get('Campaign')?.contains('ActualCost') == true) {
    // render the table without ActualCost instead of throwing
}
List<Campaign> safe = (List<Campaign>) decision.getRecords();

AccessType values: READABLE, CREATABLE, UPDATABLE, UPSERTABLE. Id is never stripped. AggregateResult is unsupported and throws. Use getModifiedIndexes() to detect that anything was stripped, and sObject.isSet('Field__c') to test a specific field.

4. Dynamic SOQL without injection

Map<String, Object> binds = new Map<String, Object>{ 'title' => '%' + userInput + '%' };
List<Personnel__c> rows = Database.queryWithBinds(
    'SELECT Id, Name, Title__c FROM Personnel__c WHERE Title__c LIKE :title',
    binds,
    AccessLevel.USER_MODE
);

Database.queryWithBinds (API 57.0+) resolves binds from a map, so the variables need not be in scope. Bind map keys are compared case-insensitively; duplicate case-variant keys throw QueryException. String.escapeSingleQuotes only helps inside single-quoted literals and is explicitly not the recommended defence. Field and object names cannot be bound: allowlist them (Set<String> of permitted API names) plus a describe accessibility check.

5. Record access beyond sharing rules: Apex managed sharing

Job__Share share = new Job__Share(
    ParentId = job.Id,
    UserOrGroupId = job.Recruiter__c,
    AccessLevel = 'Edit',
    RowCause = Schema.Job__Share.RowCause.Recruiter__c
);
Database.SaveResult sr = Database.insert(share, false, AccessLevel.USER_MODE);

Share objects are <Object>Share / MyObject__Share. Access levels: Read, Edit, All (All is managed-sharing only; None applies to AccountShare only). Apex sharing reasons (RowCause) are custom-object-only and survive owner changes; RowCause = 'Manual' shares are deleted when the owner changes. The object's OWD must not already be the most permissive setting, otherwise insert fails with FIELD_FILTER_VALIDATION_EXCEPTION. Details and the recalculation batch pattern: references/sharing-and-record-access.md.

6. Ship permission sets, not profiles

Grant all functional access through permission sets and compose them with permission set groups; use muting permission sets to subtract from a group rather than forking a permission set. Profiles stay minimal (Minimum Access - Salesforce plus license/defaults). Metadata shapes, retrieval caveats, and deployment ordering: references/permission-architecture.md.

7. Secrets never live in source

Credentials in ExternalCredential are encrypted by the platform with org-specific keys. vibe-force hooks scan writes for credential-looking literals and block them in standard and strict hook modes; vf-check analyzer flags ApexSuggestUsingNamedCred and ApexBadCrypto.

8. Client-side security

• Lightning Web Security is the default architecture for orgs created in Winter '23 and later and GA for all orgs since Summer '23; it replaces Lightning Locker with per-namespace JavaScript virtualization. Components must not override window/document functions, must load libraries via lightning/platformResourceLoader from a static resource, and must not use inline <script>.
• CSP for Lightning is default-src 'self', script-src 'self', object-src 'self', style-src 'self' https:, img-src 'self' http: https: data:, connect-src 'self', frame-src https:, frame-ancestors https:, font-src https: data:. Enable the stricter CSP org setting and develop against it. unsafe-inline and unsafe-eval are not blocked by CSP today but are rejected in AppExchange security review.
• lightning/uiRecordApi, lightning-record-form, and the other Lightning Data Service wire adapters apply sharing, CRUD, and FLS for you. Prefer them over custom @AuraEnabled data plumbing (skill sf-lwc-development).
• Every @AuraEnabled method is a public web service: assume an attacker calls it with arbitrary parameters, regardless of what your component sends.

Anti-patterns

Verification

# security-tagged static analysis (PMD + ESLint + Flow + Regex engines)
sf code-analyzer run --workspace . --rule-selector Security --view detail

# path-based CRUD/FLS analysis over Apex (Graph Engine)
sf code-analyzer run --workspace . --rule-selector sfge --target force-app/main/default/classes

# the gate vibe-force runs; fails at configured analyzerFailSeverity (default 3)
node "${CLAUDE_PLUGIN_ROOT}/scripts/checks/vf-check.mjs" analyzer --changed

# prove enforcement at runtime with a least-privilege user
sf apex run test --tests SecurityEnforcementTest --synchronous --target-org vf-dev

# confirm what a permission set actually grants in the org
sf data query --query "SELECT SobjectType, PermissionsRead, PermissionsCreate, PermissionsEdit, PermissionsDelete FROM ObjectPermissions WHERE ParentId IN (SELECT Id FROM PermissionSet WHERE Name = 'Expense_App_User')" --target-org vf-dev

Runtime proof pattern (full version in references/crud-fls-enforcement.md): create a minimum-access user, assign only the intended permission set, wrap the call in System.runAs, and assert that an unauthorized call throws System.QueryException / System.DmlException / SecurityException rather than silently returning data.

PR security checklist

1. Every class touching data has an explicit sharing declaration; triggers delegate to handlers.
2. Every SOQL/SOSL/DML has an explicit access mode; WITH SYSTEM_MODE / as system / without sharing carries a comment naming the business reason.
3. No string-concatenated user input in a query; dynamic field/object names allowlisted.
4. @AuraEnabled / @RestResource / @InvocableMethod parameters validated and never used to choose objects or fields directly.
5. No secrets in source; callouts use Named Credentials; endpoints are HTTPS (ApexInsecureEndpoint).
6. No innerHTML/lwc:dom="manual" with server data; no inline script; libraries loaded from static resources.
7. Permission sets updated in the same PR as new objects, fields, Apex classes, and pages; no profile edits.
8. Tests assert negative access with System.runAs for at least one least-privilege persona.
9. vf-check analyzer and vf-check local pass; any suppression has a rule selector, a limit, and a reason.
10. No PII in System.debug; no APEX_CODE=FINEST trace flags left active.

References

• references/crud-fls-enforcement.md - decision matrix and runnable code for every enforcement mechanism, with tests.
• references/sharing-and-record-access.md - OWD, hierarchy, sharing rules, __Share objects, recalculation, restriction rules.
• references/secure-coding-catalogue.md - vulnerability to vulnerable code to fixed code to detecting rule.
• references/permission-architecture.md - permission set, group, and muting metadata, deployment notes.
• Apex Developer Guide: Apex Security and Sharing Model - authoritative Versioned Behavior Changes list for API 67.0.
• Apex Developer Guide: Enforce Object and Field Permissions, Set an Access Mode for Database Operations, stripInaccessible, sharing keywords, Apex Managed Sharing, Dynamic SOQL
• Secure Coding Guide: CRUD/FLS, Sharing Violations, SOQL Injection, XSS, Storing Sensitive Data, Lightning Security
• LWC Developer Guide: Secure Apex Classes
• Lightning Web Security
• Metadata API: PermissionSet, PermissionSetGroup, MutingPermissionSet, ExternalCredential
• Object Reference: EventLogFile
• Sibling skills: sf-apex-development, sf-apex-testing, sf-lwc-development, sf-code-analyzer-quality, sf-debugging-logs, sf-deployment-strategies, sf-post-deploy-verification, sf-integration-patterns.