Salesforce Security Best Practices - The Architect's Checklist

Security reviews catch issues that code reviews miss. I’ve sat on both sides of the Salesforce security review table — submitting apps for AppExchange review and conducting internal architecture reviews — and the same categories of vulnerabilities come up repeatedly. CRUD and FLS enforcement gaps, missing input sanitization, over-permissioned profiles, unmonitored data exports.

This is the checklist I work through on every implementation. It’s organized by security layer so you can address each domain systematically.

The Security Layers Model

Layer 1: Network and Session Security

Checklist

• IP whitelisting configured on all integration-connected profiles
• Trusted IP ranges set per profile for admin/developer access
• MFA enforced for all users (now required by Salesforce policy)
• Session timeout set to 2 hours or less for non-service accounts
• Login hours restricted on profiles where appropriate (e.g., no overnight logins for internal staff)
• Single Sign-On (SSO) enforced via identity provider where possible — reduces password sprawl

Common Gap

Layer 2: Org-Level Access Control

Checklist

• Minimum Permission Set principle applied — no “grant all” profiles
• System Administrator profile reserved for dedicated admins only, not developers
• Modify All Data and View All Data permissions explicitly justified and documented
• API Enabled removed from end-user profiles that don’t need API access
• Custom Permissions used for feature access rather than profile hacks
• Muting Permission Sets used to reduce over-permissioning in managed packages

The Permission Set Audit Query

Run this SOQL to surface all users with Modify All Data:

SELECT PermissionSet.Label, Assignee.Name, Assignee.Profile.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
ORDER BY Assignee.Name

If this returns more than 5-10 records in a typical org, you have a problem.

Layer 3: CRUD and FLS Enforcement in Apex

This is the layer most developers under-invest in. Apex runs in system context by default — it bypasses CRUD and FLS. That means a user who can invoke your Apex (via a Flow, LWC, or API) gets whatever data access your code gives them, regardless of their profile.

WITH SECURITY_ENFORCED

// Throws QueryException if user lacks FLS read on any queried field
List<Account> accounts = [
    SELECT Id, Name, AnnualRevenue, BillingStreet
    FROM Account
    WHERE OwnerId = :UserInfo.getUserId()
    WITH SECURITY_ENFORCED
];

stripInaccessible — The Gentler Alternative

Read Operations

// Query runs, then platform strips fields the user can't see
SObjectAccessDecision decision = Security.stripInaccessible(
    AccessType.READABLE,
    [SELECT Id, Name, AnnualRevenue, SSN__c FROM Account WHERE Id = :accountId]
);

List<Account> safeAccounts = (List<Account>) decision.getRecords();
// SSN__c will be null if user lacks FLS read — no exception thrown

Write Operations

// Strip fields the user can't write before DML
SObjectAccessDecision writeDecision = Security.stripInaccessible(
    AccessType.UPDATABLE,
    accountsToUpdate
);
update writeDecision.getRecords();

Manual CRUD Checks

// Check object-level read access
if (!Schema.sObjectType.Account.isQueryable()) {
    throw new AuraHandledException('Insufficient permissions to read Accounts');
}

// Check field-level access
Schema.DescribeFieldResult fieldDescribe =
    Schema.sObjectType.Account.fields.AnnualRevenue;

if (!fieldDescribe.isAccessible()) {
    throw new AuraHandledException('Field access denied: AnnualRevenue');
}

// Check before DML
if (!Schema.sObjectType.Account.isUpdateable()) {
    throw new AuraHandledException('Insufficient permissions to update Accounts');
}

The OWASP Salesforce Top Issues

The OWASP Salesforce Security Cheat Sheet highlights:

1. SOQL Injection — Never concatenate user input into SOQL strings:

Vulnerable

String query = 'SELECT Id FROM Account WHERE Name = \'' + userInput + '\'';
List<Account> results = Database.query(query);

Safe

List<Account> results = [SELECT Id FROM Account WHERE Name = :userInput];

2. Cross-Site Scripting (XSS) — In Aura components, always use {!v.value} bound expressions, never {!v.value + someString}. In LWC, use textContent not innerHTML.

3. Open Redirect — Validate URLs before redirecting:

// Check the URL is within your known safe domains before redirect
if (!url.startsWith('https://yourorg.salesforce.com') &&
    !url.startsWith('https://yourdomain.com')) {
    throw new AuraHandledException('Invalid redirect URL');
}

Layer 4: Data Encryption

Native Encryption vs Shield Platform Encryption

Shield Platform Encryption Checklist

• Tenant Secret generated and backed up securely (losing it means losing the data)
• Encryption policy defined per field — not all fields need encryption, only PII/PCI/PHI
• Search indexes planned — deterministic encryption required for searchable fields
• Formula fields audited — formulas referencing encrypted fields return masked values
• Apex code reviewed — String.valueOf() on encrypted fields returns the unmasked value, check who can call those methods

Layer 5: Event Monitoring

Event Monitoring (available with Event Monitoring add-on or Shield) gives you detailed logs for:

• Login events (including failed logins and geolocation)
• Report exports (who exported what, and how many records)
• REST API usage (which integrations are doing what)
• UI tracking events

Key Queries for Security Review

Failed Logins

SELECT EventDate, Username, SourceIp, LoginType
FROM LoginEvent
WHERE LoginType != 'Application'
  AND EventDate = LAST_N_DAYS:30
ORDER BY EventDate DESC

Large Exports

SELECT EventDate, Username, ReportName, NumberOfColumns, RowsProcessed
FROM ReportEvent
WHERE RowsProcessed > 5000
  AND EventDate = LAST_N_DAYS:7
ORDER BY RowsProcessed DESC

Unexpected API Access

SELECT EventDate, Username, SourceIp, ApiType
FROM ApiEvent
WHERE SourceIp NOT IN ('10.0.0.1', '10.0.0.2')
  AND EventDate = LAST_N_DAYS:1

Real-Time Event Monitoring with Platform Events

For immediate response to security events, subscribe to LoginEventStream in a Platform Event trigger:

trigger LoginEventTrigger on LoginEventStream (before insert) {
    for (LoginEventStream event : Trigger.new) {
        if (event.LoginType == 'Application' && event.Country != 'US') {
            // Alert security team via email/Slack
        }
    }
}

Layer 6: Connected App and Integration Security

Checklist

• Named Credentials used for all outbound callouts — no credentials stored in Custom Settings or code
• Connected App scopes limited to minimum required (avoid full scope)
• Client Credential OAuth flow used for server-to-server integrations, not password flow
• Refresh token rotation enabled on OAuth Connected Apps
• IP enforcement enabled on integration-specific profiles
• REST API access restricted via Permission Set (not profile) for integration users

Named Credentials in Apex

// Always use Named Credentials — never hardcode tokens
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_Integration_NC/api/v1/accounts');
req.setMethod('GET');
req.setHeader('Content-Type', 'application/json');

Http http = new Http();
HttpResponse res = http.send(req);

The Pre-Go-Live Security Checklist

Print this and work through it before any production launch:

• Health Check score is above 90
• Guest user profile has no object access (unless explicitly needed)
• No active users with “Manage Users” who are not administrators
• All Apex classes use CRUD/FLS enforcement or have documented justification
• No SOQL queries built with string concatenation
• Session timeout is 2 hours or less
• MFA is enforced for all users
• No Named Credentials with stored passwords (use OAuth)
• Event Monitoring alerts configured for failed logins and large exports
• Encryption policy defined for any PII fields
• Guest user sharing rules reviewed (especially for Community/Experience Cloud sites)

Security is never “done” — it’s a continuous practice. Salesforce’s Trust site publishes regular security advisories, and the platform evolves. Schedule a quarterly security review in your calendar and work through this checklist each time.

What’s the security gap you see most often in Salesforce implementations? I’ve found CRUD/FLS enforcement in Apex to be the single biggest blind spot — developers simply don’t think about it until a security review forces the issue. Drop your observations in the comments, especially if you’ve caught something unusual in a review that isn’t on this checklist.

Test Your Knowledge

🎉

You finished this article!

Share it with your network — here's a ready-made post with an image.

Download Share Image

𝕏 / Twitter Copy

Salesforce Security Best Practices - The Architect's Checklist A comprehensive security checklist for Salesforce architects covering CRUD/FLS enforcement, Shield encryption, Event Mon... https://forcenaut.com/blog/salesforce-security-architect-checklist #Salesforce #Architecture #Trailblazer

Post on X

LinkedIn Copy

Salesforce Security Best Practices - The Architect's Checklist A comprehensive security checklist for Salesforce architects covering CRUD/FLS enforcement, Shield encryption, Event Monitoring, and OWASP-aligned Apex patterns. Read more: https://forcenaut.com/blog/salesforce-security-architect-checklist #Salesforce #Architecture #Trailblazer

Share on LinkedIn

Tip: Download the image, then paste it along with the copied text when posting for maximum engagement.

Comments

Sign in to comment

Google GitHub

Sign out

Replying to Cancel

0/2000

Post Comment

Admin Mode