Salesforce Security: The Ultimate Guide to Preventing Hacks

01 The 2025 Salesforce Breach Wave: What Happened?

In 2025, the Salesforce ecosystem experienced an unprecedented series of coordinated attacks. Understanding what happened is the first step to preventing similar incidents in your organization.

Major Incidents Timeline

To put the campaign in perspective: researchers estimate the overall 2025 ShinyHunters campaign against Salesforce customers exposed roughly 70 million records in aggregate, spread across thousands of organizations. That figure describes the entire campaign - no single victim accounted for it.

How the Attacks Worked

The breaches were not due to Salesforce platform vulnerabilities. As documented in Salesforce Trust notifications, the attacks exploited:

1. Social Engineering (Vishing): Attackers posed as Salesforce support staff, calling employees and convincing them to install malicious software
2. OAuth Token Abuse: Once access was gained, attackers used legitimate OAuth features to exfiltrate data
3. Supply Chain Compromise: The Salesloft-Drift integration was compromised, providing OAuth tokens to hundreds of organizations
4. Browser Extension Attacks: In December 2024, at least 35 Chrome extensions were compromised in a supply chain attack, exposing session cookies and credentials of roughly 2.6 million users; a related February 2025 GitLab analysis found malicious extensions impacting 3.2+ million users (See Section 14)

02 Salesforce Security Health Check

The Security Health Check is your first line of defense. It's a built-in tool that scores your org's security settings from 0-100.

Step-by-Step: Running Health Check

Key Settings to Review

03 Multi-Factor Authentication (MFA)

Since February 2022, MFA is contractually required for all Salesforce customers. Even if credentials are stolen, MFA adds a second check that an attacker also has to pass. It lowers the risk a lot but is not a guarantee, for example when a user approves a fake prompt.

Step-by-Step: Enable MFA for All Users

Supported MFA Methods

04 Session Security Settings

Session settings control how long users stay logged in and what protections are applied during their session. Proper configuration prevents session hijacking and limits exposure if credentials are compromised.

Critical Session Settings

Navigate to Setup > Session Settings to configure these settings:

Login IP Restrictions (Profile Level)

According to Salesforce Trailhead security module, you can restrict login to specific IP ranges per profile:

Login Hours Restrictions

Limit when users can log in to reduce off-hours attack windows:

05 Permission Sets & Least Privilege

The principle of least privilege is fundamental: users should have only the minimum permissions needed to do their job. This limits the blast radius of any security incident.

Step-by-Step: Audit High-Risk Permissions

Dangerous Permissions to Review

How to Find Over-Privileged Users

-- SOQL Query: Find users with Modify All Data permission
SELECT Id, Name, Profile.Name
FROM User
WHERE Profile.PermissionsModifyAllData = true
AND IsActive = true

-- Find all permission sets with View All Data
SELECT Id, Name, PermissionsViewAllData
FROM PermissionSet
WHERE PermissionsViewAllData = true

Best Practice: Permission Set Architecture

06 Field-Level Security (FLS)

Field-Level Security controls which fields users can see and edit. According to Salesforce data security documentation, FLS is enforced across all parts of Salesforce including reports, list views, and search results.

Configuring FLS for Sensitive Fields

Enforcing FLS in Apex Code

According to Apex developer documentation, Apex has historically run in system context by default, bypassing FLS - which meant you had to explicitly enforce security in code.

Method 1: User Mode Queries (Recommended - GA Spring '23, API v57; default at API v67+)

// RECOMMENDED: User mode automatically enforces CRUD and FLS
List<Account> accounts = [
    SELECT Id, Name, AnnualRevenue, Phone
    FROM Account
    WITH USER_MODE
];

// For DML operations
Database.insert(newAccounts, AccessLevel.USER_MODE);

Method 2: WITH SECURITY_ENFORCED

// Throws exception if user lacks field access
List<Contact> contacts = [
    SELECT Id, Name, Email, SSN__c
    FROM Contact
    WITH SECURITY_ENFORCED
];
// If user can't see SSN__c, query throws System.QueryException

Method 3: Manual Security Checks

public class SecureContactController {

    public static List<Contact> getContacts() {
        // Check object-level access
        if (!Schema.sObjectType.Contact.isAccessible()) {
            throw new AuraHandledException('You do not have access to Contacts');
        }

        // Check field-level access
        if (!Schema.sObjectType.Contact.fields.Email.isAccessible()) {
            throw new AuraHandledException('You do not have access to Email field');
        }

        return [SELECT Id, Name, Email FROM Contact LIMIT 100];
    }

    public static void updateContact(Contact con) {
        // Check update permission
        if (!Schema.sObjectType.Contact.isUpdateable()) {
            throw new AuraHandledException('You cannot update Contacts');
        }

        // Check field update permission
        if (!Schema.sObjectType.Contact.fields.Email.isUpdateable()) {
            throw new AuraHandledException('You cannot update Email field');
        }

        update con;
    }
}

07 OAuth, Connected Apps & External Client Apps Security

Connected Apps and OAuth tokens were the primary attack vector in the 2025 breach wave. According to Salesforce Connected Apps documentation, proper configuration is essential. Salesforce's current direction is external client apps: the Winter '27 release notes say that connected apps keep working but lose support in Summer '27. This section keeps the connected app advice that still applies and adds the migration path and the flows being retired.

What Winter '27 Changes for Connected Apps and OAuth Flows

The wording below is quoted from the Salesforce release notes and Help article (Winter '27, release 264; read in October 2026). Check the Release Updates page in your own org, because enforcement dates and test run options are shown there.

Migrating a Connected App to an External Client App

Building a New External Client App

New integrations should start as external client apps. The Summer '26 release note says "by default, Salesforce blocks you from creating new connected apps", and in the orgs I tried, creating one gave: "You can't create a connected app. To enable connected app creation, contact Salesforce Customer Support." Salesforce also enforces OAuth security controls for new apps: "The Proof Key for Code Exchange (PKCE) extension is required for apps that use the authorization code grant type. For apps that use the refresh token flow, Salesforce requires two controls: refresh token rotation and a 30-day limit to the time-to-live (TTL) for idle refresh tokens." Those settings come ticked and locked on a new app.

Finding SOAP login() Callers

Salesforce's Help article "Platform SOAP API login() Retirement & new Security Requirements" says to use Login History: look for entries with LoginType "Other Apex API" or "Partner Product", Login Subtype "SOAP API", and API Type "SOAP Enterprise", "SOAP Partner" or "SOAP Tooling". "The Application field shows N/A to indicate that the SOAP client isn't bound to a connected app or external client app." Replacements it names: "For server-to-server or headless integration, use either the OAuth 2.0 JWT bearer flow or the OAuth 2.0 client credentials flow. For browser-based or user-driven integration, use the OAuth 2.0 web server flow." Source: Salesforce Help article 005132110.

Step-by-Step: Secure Connected App Configuration

Still applies: these steps cover the connected apps you keep until you migrate them, and the same questions (who can authorize, how long tokens live, where tokens can be used) apply to external client apps. Setup labels for external client apps differ, so check the screen in your org.

Connected App Security Checklist

Code: Creating a Secure Connected App

This metadata example is for reference. Orgs that block new connected apps will refuse to deploy it, and new integrations should be built as external client apps.

{
    "fullName": "Secure_Integration_App",
    "label": "Secure Integration App",
    "oauthConfig": {
        "callbackUrl": "https://your-app.com/oauth/callback",
        "isAdminApproved": true,
        "scopes": ["api", "refresh_token"],
        "isSecretRequiredForRefreshToken": true,
        "isCodeCredentialPostOnly": true
    },
    "oauthPolicy": {
        "ipRelaxation": "ENFORCE",
        "refreshTokenPolicy": "SPECIFIC_EXPIRATION",
        "refreshTokenValidityPeriod": 90,
        "singleLogoutUrl": "https://your-app.com/logout"
    }
}

08 SOQL Injection Prevention

SOQL injection is one of the OWASP Top 10 vulnerabilities. It occurs when user input is directly concatenated into dynamic SOQL queries, allowing attackers to modify query logic.

Vulnerable vs. Secure Code Examples

VULNERABLE: Direct String Concatenation

// DANGEROUS - DO NOT USE
public List<Account> searchAccounts(String searchTerm) {
    String query = 'SELECT Id, Name FROM Account WHERE Name = \'' + searchTerm + '\'';
    return Database.query(query);
}

// Attacker input: ' OR Name != '
// Results in: SELECT Id, Name FROM Account WHERE Name = '' OR Name != ''
// Returns ALL accounts!

SECURE Method 1: Static Queries with Bind Variables (Recommended)

// SECURE - Bind variable prevents injection
public List<Account> searchAccounts(String searchTerm) {
    return [SELECT Id, Name FROM Account WHERE Name = :searchTerm];
}

// Even better: Use LIKE with bind variable
public List<Account> searchAccountsLike(String searchTerm) {
    String sanitizedTerm = '%' + searchTerm + '%';
    return [SELECT Id, Name FROM Account WHERE Name LIKE :sanitizedTerm];
}

SECURE Method 2: escapeSingleQuotes (When Dynamic SOQL Required)

// SECURE - Escapes single quotes in user input
public List<Account> dynamicSearch(String searchTerm) {
    String escapedTerm = String.escapeSingleQuotes(searchTerm);
    String query = 'SELECT Id, Name FROM Account WHERE Name LIKE \'%' + escapedTerm + '%\'';
    return Database.query(query);
}

SECURE Method 3: Database.queryWithBinds (GA Spring '23, API v57+)

// SECURE - Modern approach with bind map
public List<Account> modernSearch(String searchTerm, String industry) {
    String query = 'SELECT Id, Name, Industry FROM Account WHERE Name LIKE :searchTerm';

    if (String.isNotBlank(industry)) {
        query += ' AND Industry = :industry';
    }

    Map<String, Object> bindMap = new Map<String, Object>{
        'searchTerm' => '%' + searchTerm + '%',
        'industry' => industry
    };

    return Database.queryWithBinds(query, bindMap, AccessLevel.USER_MODE);
}

Handling Non-String Inputs

According to Salesforce Apex Developer Guide, escapeSingleQuotes doesn't protect against all injection types:

// VULNERABLE - Boolean injection
String isActiveInput = 'true OR ReceivesAdminInfoEmails=true';
String query = 'SELECT Id FROM User WHERE IsActive=' + String.escapeSingleQuotes(isActiveInput);
// Injection succeeds because no quotes are needed!

// SECURE - Typecast to enforce data type
public List<User> getUsersByStatus(String isActiveInput) {
    Boolean isActive;
    try {
        isActive = Boolean.valueOf(isActiveInput);
    } catch (Exception e) {
        throw new AuraHandledException('Invalid input');
    }
    return [SELECT Id, Name FROM User WHERE IsActive = :isActive];
}

09 Cross-Site Scripting (XSS) Prevention

XSS attacks inject malicious scripts into web pages viewed by other users. Salesforce has built-in protections, but developers must follow best practices to avoid creating vulnerabilities.

XSS in Visualforce Pages

VULNERABLE: Unescaped Output

<!-- DANGEROUS - escape="false" allows XSS -->
<apex:outputText value="{!userInput}" escape="false" />

<!-- DANGEROUS - Direct output in JavaScript -->
<script>
    var name = '{!JSENCODE(userInput)}'; // Must use JSENCODE
</script>

SECURE: Proper Escaping

<!-- SECURE - Default behavior escapes HTML -->
<apex:outputText value="{!userInput}" />

<!-- SECURE - Explicit HTML encoding -->
<apex:outputText value="{!HTMLENCODE(userInput)}" />

<!-- SECURE - For JavaScript contexts -->
<script>
    var name = '{!JSENCODE(userInput)}';
    var data = {!JSINHTMLENCODE(jsonData)};
</script>

<!-- SECURE - For URL parameters -->
<a href="/page?param={!URLENCODE(userInput)}">Link</a>

XSS in Lightning Web Components

According to Salesforce LWS Sanitization documentation, LWC provides automatic HTML escaping by default, but DOM manipulation can introduce vulnerabilities:

// SECURE - Template expressions are auto-escaped
<template>
    <p>{userInput}</p> <!-- Automatically escaped -->
</template>

// VULNERABLE - Direct innerHTML assignment
connectedCallback() {
    // DANGEROUS - Allows XSS (even with LWS, user input should be validated)
    this.template.querySelector('div').innerHTML = this.userInput;
}

// SECURE - Use textContent for plain text
connectedCallback() {
    // SAFE - textContent escapes HTML
    this.template.querySelector('div').textContent = this.userInput;
}

// RECOMMENDED - Use lightning-formatted-rich-text for HTML content
// In your template:
<template>
    <lightning-formatted-rich-text value={richTextContent}>
    </lightning-formatted-rich-text>
</template>
// The component automatically sanitizes HTML and only allows safe tags

Using lightning-formatted-rich-text (Recommended)

The lightning-formatted-rich-text component automatically sanitizes HTML to prevent XSS:

// HTML template
<template>
    <lightning-formatted-rich-text
        value={userProvidedHtml}>
    </lightning-formatted-rich-text>
</template>

// Supported tags (all others are stripped):
// a, abbr, b, br, big, blockquote, code, del, div, em,
// h1-h6, hr, i, img, ins, li, ol, p, pre, s, small,
// span, strong, sub, sup, table, tbody, td, th, tr, u, ul

Encoding Functions Reference

10 Cross-Site Request Forgery (CSRF) Protection

CSRF attacks trick authenticated users into performing unwanted actions. Salesforce has built-in CSRF protection, but there are edge cases developers must handle.

Salesforce Built-in Protection

According to the Salesforce Secure Coding Guide (v67.0, Summer '26), CSRF protection is automatically enabled:

• Visualforce Pages: Automatic CSRF tokens included in forms
• Lightning Web Components: Protected via Lightning Web Security (LWS); legacy Aura contexts still rely on Lightning Locker
• REST API: Session ID acts as CSRF token

Known Vulnerability: Page Load DML

// VULNERABLE - DML in page constructor
public class VulnerableController {
    public VulnerableController() {
        // DANGEROUS - Executes before CSRF check completes
        delete [SELECT Id FROM Task WHERE OwnerId = :UserInfo.getUserId()];
    }
}

// VULNERABLE in LWC - DML on load
@AuraEnabled
public static void riskyMethod() {
    // Don't call this from connectedCallback()!
    delete [SELECT Id FROM Task LIMIT 10];
}

// SECURE - Require explicit user action
public PageReference deleteRecords() {
    // Safe - Called via button click after page fully loaded
    if (ApexPages.currentPage().getParameters().containsKey('confirm')) {
        delete [SELECT Id FROM Task WHERE OwnerId = :UserInfo.getUserId()];
    }
    return null;
}

LWC Best Practices

// VULNERABLE - DML on component load
connectedCallback() {
    deleteRecords(); // DON'T DO THIS
}

// SECURE - Require user interaction
handleDeleteClick() {
    // Show confirmation first
    if (confirm('Are you sure?')) {
        deleteRecords();
    }
}

REST API CSRF Considerations

// When making API calls from external apps, include session token
fetch('/services/data/v65.0/sobjects/Account', {
    method: 'POST',
    headers: {
        'Authorization': 'Bearer ' + sessionId,
        'Content-Type': 'application/json',
        // Salesforce validates session ID as CSRF token
    },
    body: JSON.stringify(accountData)
});

11 Shield Platform Encryption

Shield Platform Encryption provides an extra layer of protection by encrypting sensitive data at rest. It's part of the Salesforce Shield add-on product.

What Shield Encryption Protects

Step-by-Step: Enable Shield Encryption

Bring Your Own Key (BYOK)

For maximum control, organizations can manage their own encryption keys:

# Generate key material using OpenSSL
openssl rand -out customer-key.bin 32

# Wrap the key with Salesforce certificate (obtained from Setup)
openssl pkeyutl -encrypt \
    -in customer-key.bin \
    -out wrapped-key.bin \
    -pubin -inkey salesforce-cert.pem \
    -pkeyopt rsa_padding_mode:oaep \
    -pkeyopt rsa_oaep_md:sha256

12 Event Monitoring & Auditing

Continuous monitoring is essential for detecting security incidents early. According to Salesforce Event Monitoring documentation, comprehensive logging enables rapid incident response.

Built-in Monitoring Tools (Free)

1. Login History

Setup > Login History > View last 20,000 logins (6 months via CSV export)

-- Query login history in Apex
SELECT Id, UserId, LoginTime, SourceIp, Status, Application, Browser
FROM LoginHistory
WHERE LoginTime > LAST_N_DAYS:7
ORDER BY LoginTime DESC

2. Setup Audit Trail

Setup > View Setup Audit Trail > The 20 most recent setup changes; click Download for the full setup history of the past 180 days (Salesforce Help)

-- Query setup changes
SELECT Id, CreatedDate, CreatedById, CreatedBy.Name, Action, Section, Display
FROM SetupAuditTrail
WHERE CreatedDate > LAST_N_DAYS:30
ORDER BY CreatedDate DESC

3. Field History Tracking

Enable on sensitive fields to track who changed what and when.

Event Monitoring (Shield - Paid)

Shield Event Monitoring provides comprehensive visibility:

Setting Up Real-Time Alerts

// Example to adapt: Apex condition for a policy created in Real-Time Event Monitoring.
// evaluate() returns true when the event triggers the policy.
global class HighVolumeAPIPolicy implements TxnSecurity.EventCondition {
    public Boolean evaluate(SObject event) {
        ApiEvent apiEvent = (ApiEvent) event;
        // Trigger when one API request processes more than 50,000 rows
        return apiEvent.RowsProcessed != null && apiEvent.RowsProcessed > 50000;
    }
}
// The ApiEvent field and the 50,000-row threshold are illustrative; adapt them.
// Test the policy in a sandbox with Notify before you switch the action to Block.

13 Social Engineering Defense

The 2025 breaches primarily used social engineering - attackers calling employees and convincing them to install malicious software. According to Salesforce Security Best Practices, technical controls alone aren't enough.

Common Attack Scenarios

Security Awareness Training Checklist

Technical Controls Against Social Engineering

1. Block Uninstalled Connected Apps: Prevents users from authorizing rogue apps (enabled by default in Sept 2025+)
2. Require Admin App Approval: All OAuth apps need admin pre-authorization
3. High Assurance MFA: Require MFA for all logins, not just first-time
4. IP Restrictions: Limit login to known corporate IPs/VPN
5. Real-Time Alerts: Notify admins of unusual login patterns
6. Browser Extension Controls: Implement allowlisting to prevent malicious extensions - Salesforce's app controls (such as Connected Apps) do not cover them (See Section 14)

14 Browser Extension Security Risks: The Hidden Threat to Your Salesforce Data

Salesforce Chrome extensions have become an essential part of many users' workflows, offering productivity enhancements and automation capabilities. However, these same extensions represent a significant and often overlooked security vulnerability that can lead to devastating data breaches.

How Chrome Extensions Can Compromise Salesforce Security

Browser extensions operate with significant privileges that can bypass Salesforce's built-in security controls:

Why Extensions Are Hard to See With Salesforce Security Controls

Unlike Connected Apps that use OAuth and appear in Salesforce's security dashboards, browser extensions are not identified as apps in Salesforce. This makes them dangerous and difficult to detect.

How Extensions Bypass Salesforce Authentication

When you log into Salesforce, your browser stores a session cookie (the sid cookie). This cookie is what keeps you logged in as you navigate between pages. Here's the critical security gap:

// Normal OAuth Flow (Visible to Salesforce)
// 1. App redirects to Salesforce login
// 2. User authenticates and grants permission
// 3. Salesforce issues access_token to the app
// 4. App uses token for API calls -> LOGGED in Connected Apps OAuth Usage

// Browser Extension Flow (not identified as an app in Salesforce)
// 1. User logs into Salesforce normally
// 2. Browser stores session cookie (sid)
// 3. Extension reads the cookie OR reads page content directly
// 4. Extension acts with the user's permissions -> attributed to the user, not to an app

// Extension accessing data - Salesforce sees this as the USER, not an app
chrome.cookies.get({url: "https://mycompany.my.salesforce.com", name: "sid"},
    function(cookie) {
        // Extension now has full session access
        // Can make requests that appear to come from the user
        fetch("https://mycompany.my.salesforce.com/services/data/v65.0/query?q=SELECT+Id,Name+FROM+Account", {
            headers: { "Authorization": "Bearer " + cookie.value }
        });
        // This API call is attributed to the USER, not any "app"
    }
);

// Even worse - DOM scraping requires NO API calls at all
// Extension just reads what's already displayed on screen
document.querySelectorAll('.slds-table tbody tr').forEach(row => {
    // Silently capture all visible record data
    // No API calls, so no API events for this activity
    exfiltrateToAttacker(row.innerText);
});

Real-World Extension Attack Scenarios

Dangerous Extension Permissions to Watch For

When reviewing Chrome extensions, these permissions should raise immediate red flags for Salesforce users:

Host Permissions - Salesforce Targeting

{
  "host_permissions": [
    "*://*.salesforce.com/*",
    "*://*.force.com/*",
    "*://*.lightning.force.com/*",
    "*://*.my.salesforce.com/*",
    "*://*.cloudforce.com/*"
  ]
}

These patterns match hosts under salesforce.com (including my.salesforce.com), force.com (including lightning.force.com) and cloudforce.com. Any other domain your org uses, such as a custom domain for an Experience Cloud site, is not covered and must be added to the list.

Technical Deep Dive: How Extensions Steal Salesforce Sessions

Understanding the attack mechanics helps you appreciate why this threat is so serious:

// Example: How a malicious extension can steal Salesforce session
// THIS IS FOR EDUCATIONAL PURPOSES - showing what attackers do

// 1. Read Salesforce session cookie
chrome.cookies.get({
    url: "https://yourcompany.my.salesforce.com",
    name: "sid"
}, function(cookie) {
    // Session ID captured - attacker can now impersonate user
    exfiltrateData(cookie.value);
});

// 2. Intercept API responses containing sensitive data
chrome.webRequest.onCompleted.addListener(
    function(details) {
        // Capture all Salesforce API responses
        if (details.url.includes('/services/data/')) {
            // Record data is being exfiltrated
        }
    },
    {urls: ["*://*.salesforce.com/*"]}
);

// 3. Inject keylogger on Salesforce login page
if (window.location.hostname.includes('salesforce.com')) {
    document.addEventListener('keydown', function(e) {
        // Every keystroke sent to attacker's server
        sendToC2Server(e.key);
    });
}

Protection Strategies for Organizations

Chrome Enterprise Policy Configuration

For organizations using Google Workspace or Chrome Enterprise, implement these policies to protect Salesforce access:

{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": [
    "eimadpbcbfnmbkopoojfekhnkhdbieeh",
    "cjpalhdlnbpafiamejdnhcphjbkeiagm",
    "hdokiejnpimakedhajhdlcegeplioahd"
  ],
  "ExtensionInstallForcelist": [
    "your-security-ext-id;https://your-domain.com/update.xml"
  ],
  "ExtensionAllowedTypes": ["extension", "theme"],
  "ExtensionSettings": {
    "*": {
      "runtime_blocked_hosts": [
        "*://*.salesforce.com",
        "*://*.force.com"
      ]
    }
  }
}

• ExtensionInstallBlocklist: ["*"] blocks all extensions by default (zero-trust approach).
• ExtensionInstallAllowlist lists the only extension IDs that can be installed. The three IDs shown are examples (Dark Reader, uBlock Origin, LastPass); replace them with your vetted extensions.
• ExtensionInstallForcelist auto-installs corporate security extensions. The ID and update URL are placeholders.
• ExtensionAllowedTypes allows only extensions and themes (no hosted apps).
• runtime_blocked_hosts blocks extensions from accessing the listed hosts. Patterns hold only scheme, host and domain (no path); add any custom domain your org uses.

User Guidelines for Safe Extension Usage

1. Never install extensions from email links - Always go directly to Chrome Web Store
2. Check publisher verification - Look for the verified publisher badge in Chrome Web Store
3. Review permissions carefully - Reject extensions asking for more access than they need
4. Check reviews and user count - Be suspicious of new extensions with few users
5. Audit installed extensions monthly - Remove any you no longer actively use
6. Use separate browser profiles - Keep Salesforce access in a clean profile
7. Report suspicious extensions - Notify IT security immediately if an extension behaves unexpectedly

Evaluating Salesforce Extensions Before Installation

Incident Response: If You Suspect Extension Compromise

15 Complete Security Checklist

Use this comprehensive checklist to audit and secure your Salesforce org. Review quarterly at minimum.

Authentication & Access (Priority: Critical)

Permissions & Data Access (Priority: High)

Connected Apps & Integrations (Priority: Critical)

Browser Extension Security (Priority: Critical)

Code Security (Priority: High)

Monitoring & Response (Priority: Medium)

For related reading, see 7 Ways to Secure Experience Cloud for guest user access and sharing rules, Apex Design Patterns for maintainable Apex that pairs with the secure coding practices here, the Salesforce Scale Center Complete Guide for spotting anomalous request patterns, and 10 Differences Between Salesforce Solution and Technical Architect for how architect roles divide security ownership.

16 Frequently Asked Questions

17 Abbreviations & Glossary