Salesforce Security
Jitendra's Blog
COMPLETE SECURITY GUIDE

Salesforce Security: The Ultimate Guide to Preventing Hacks

Step-by-step instructions, code examples, and checklists to protect your org from data breaches and social engineering attacks

700+
Orgs Breached in 2025
15
Sections Covered
30+
Checklist Items
100%
Admin Friendly

1 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.

Critical Alert: According to security industry reports, over 700 organizations had their Salesforce instances compromised through social engineering and OAuth abuse in 2025.

Major Incidents Timeline

Date Company Impact
June 2025 Google 2.55 million customer records exposed
July 2025 Allianz Life Customer data compromised via ShinyHunters
August 2025 Chanel, Pandora Fashion brands targeted in coordinated attack
August 2025 Workday 70 million user records accessed
August 2025 Farmers Insurance 1.1 million customer records disclosed
Aug 2025 Airlines (KLM, Air France, etc.) Passenger data and loyalty numbers exposed

How the Attacks Worked

The breaches were not due to Salesforce platform vulnerabilities. As noted by Salesforce Security Advisories, 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, 35+ Chrome extensions were compromised in a supply chain attack, stealing session cookies and credentials from 3.7 million users (See Section 14)

Key Lesson: A secure platform doesn't guarantee a secure org. Most breaches result from misconfiguration and social engineering, not technical exploits.

2 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

1

Navigate to Health Check

Go to Setup → Quick Find → Type "Health Check" → Click Health Check

2

Review Your Score

Your org receives a score from 0-100. Aim for 80+ as a minimum. Below 60 indicates critical security gaps.

3

Fix High-Risk Issues

Click Fix Risks to automatically apply recommended settings, or click individual settings to configure manually.

Key Settings to Review

Setting Risk Level Recommended Value
Password Minimum Length High 12+ characters
Password Complexity High Must include letters, numbers, special chars
Session Timeout Medium 2 hours or less
Lock Sessions to IP Medium Enabled (if users don't roam)
Require HTTPS High Always enabled

Pro Tip: According to Salesforce Security Implementation Guide, you can create up to 5 custom baselines to measure against your organization's specific security requirements instead of the default Salesforce Baseline.

3 Multi-Factor Authentication (MFA)

Since February 2022, MFA is contractually required for all Salesforce customers. Even if credentials are stolen, MFA prevents unauthorized access.

Step-by-Step: Enable MFA for All Users

1

Configure Session Settings

Go to SetupSession Settings → Scroll to Session Security Levels → Move Multi-Factor Authentication to the High Assurance column → Click Save

2

Create MFA Permission Set

Go to SetupPermission Sets → Click New → Name it "MFA_Required" → Save

3

Enable MFA Permission

In your new permission set, click System Permissions → Click Edit → Enable "Multi-Factor Authentication for User Interface Logins" → Save

4

Assign to All Users

Click Manage AssignmentsAdd Assignment → Select all users → Assign

Supported MFA Methods

Method Description Best For
Salesforce Authenticator Push notifications, location-based auto-approval Most users (recommended)
TOTP Apps Google Authenticator, Microsoft Authenticator, Authy Users preferring third-party apps
Security Keys YubiKey, Titan Security Key (USB/NFC) High-security users, admins
Built-in Authenticators Touch ID, Face ID, Windows Hello Users with biometric devices

DO

  • Require users to register multiple MFA methods as backup
  • Use MFA with Single Sign-On (SSO) for layered security
  • Train users on recognizing fake MFA prompts
  • Set up admin procedures for MFA reset requests

DON'T

  • Rely solely on Trusted IP Ranges (doesn't satisfy MFA requirement)
  • Allow users to skip MFA setup
  • Share MFA devices between users
  • Approve MFA requests without verifying the login attempt

4 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 SetupSession Settings to configure these settings:

Setting Recommended Value Why
Session Timeout 2 hours (or less for sensitive data) Limits exposure from unattended sessions
Force Logout on Session Timeout Enabled Prevents token reuse after timeout
Lock Sessions to IP Address Enabled (if users don't roam) Prevents session hijacking from other IPs
Lock Sessions to Domain Enabled Prevents cross-domain session theft
Clickjack Protection Enabled for all pages Prevents UI redressing attacks
Require Secure Connections (HTTPS) Enabled Encrypts all traffic

Login IP Restrictions (Profile Level)

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

1

Navigate to the Profile

Go to SetupProfiles → Select the profile → Login IP Ranges

2

Add Allowed IP Ranges

Click New → Enter Start IP and End IP → Add description (e.g., "Corporate VPN") → Save

Login Hours Restrictions

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

1

Configure Login Hours

Go to SetupProfiles → Select profile → Login Hours → Click Edit

2

Set Allowed Hours

Click and drag to select allowed hours for each day. Gray means blocked, colored means allowed.

Important: Login IP restrictions and hours are enforced only at login time. Users already logged in won't be kicked out if they exceed these restrictions during an active session.

5 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.

Note: Salesforce announced that permissions on Profiles will be retired in Spring '26. Start migrating to Permission Sets and Permission Set Groups now.

Step-by-Step: Audit High-Risk Permissions

Dangerous Permissions to Review

Permission Risk Who Should Have It
Modify All Data Critical System Admin only
View All Data Critical Auditors, limited admins
Manage Users High User admins only
Author Apex High Developers only (not in prod)
API Enabled Medium Integration users, power users
Export Reports Medium Approved analysts only

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

1

Create Role-Based Permission Sets

Create separate permission sets for each function: "Sales_Read", "Sales_Create", "Sales_Admin"

2

Group into Permission Set Groups

Combine permission sets into groups: "Sales_User_Group" includes Sales_Read + Sales_Create

3

Assign Groups to Users

Assign users to permission set groups rather than individual permission sets for easier management

DO

  • Use Minimum Access profile as the base
  • Grant permissions through Permission Sets only
  • Review permissions quarterly
  • Remove permissions when roles change

DON'T

  • Clone System Administrator profile
  • Give "Modify All Data" to resolve access issues
  • Leave terminated users active
  • Create user-specific permission sets

6 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

1

Navigate to Field

SetupObject Manager → Select Object → Fields & Relationships → Select Field

2

Set Field-Level Security

Click Set Field-Level Security → Configure Visible/Read-Only for each profile → Save

Enforcing FLS in Apex Code

According to Apex developer documentation, Apex runs in system context by default, bypassing FLS. You must explicitly enforce security.

Method 1: User Mode Queries (Recommended - Summer '23+)

// 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;
    }
}

Security Alert: Never use without sharing keyword unless absolutely necessary. It bypasses sharing rules and can expose sensitive data. If you must use it, document why and review regularly.

7 OAuth & Connected 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.

2025 Update: As of September 2025, Salesforce eliminated OAuth Device Flow and blocks uninstalled Connected Apps by default for most users.

Step-by-Step: Secure Connected App Configuration

1

Audit Existing Connected Apps

SetupConnected Apps OAuth Usage → Review all apps and their access levels

2

Block Untrusted Apps

For any unknown apps, click Block to immediately revoke access and prevent future connections

3

Configure Admin-Approved Authorization

For each Connected App: ManageEdit Policies → Set Permitted Users to "Admin approved users are pre-authorized"

4

Set Token Expiration

Under OAuth Policies, set Refresh Token Expiration to 90 days or less. Enable Refresh Token Rotation.

Connected App Security Checklist

Require MFA for Connected Apps: Under OAuth Policies, select "High Assurance session required"
Use Dedicated Integration Users: Create specific user accounts for each integration with minimum required permissions
Enable PKCE: Use Proof Key for Code Exchange for mobile and JavaScript apps
Limit Scopes: Request only the minimum API scopes needed (avoid "full" scope)
Enable IP Restrictions: Add IP Relaxation policies to limit where tokens can be used
Monitor OAuth Usage: Regularly review Connected Apps OAuth Usage for unusual patterns

Code: Creating a Secure Connected App

// Connected App metadata example (for reference)
{
    "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"
    }
}

Important Distinction: While Connected Apps appear in OAuth Usage reports and can be managed through Setup, browser extensions operate completely outside Salesforce's visibility. Extensions piggyback on user sessions and never appear in any Salesforce security dashboard. See Section 14: Browser Extension Risks to understand this hidden threat vector.

8 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 (Summer '23+)

// 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];
}

DO

  • Use static SOQL with bind variables whenever possible
  • Use escapeSingleQuotes() for string values in dynamic SOQL
  • Typecast non-string inputs (Integer, Boolean, Date)
  • Validate input format with regex before use
  • Use Database.queryWithBinds() for complex dynamic queries

DON'T

  • Concatenate user input directly into queries
  • Trust escapeSingleQuotes alone for non-string values
  • Build ORDER BY or LIMIT clauses from user input
  • Allow users to specify field names dynamically

9 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

Best Practice: According to Salesforce Trailhead security module, avoid using lwc:dom="manual" wherever possible. Let LWC manipulate the DOM - it provides the best sanitization through Lightning Web Security (LWS).

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

Function Context Use Case
HTMLENCODE() HTML body Text displayed in HTML elements
JSENCODE() JavaScript strings Values in JS string literals
JSINHTMLENCODE() JS in HTML JS in onclick handlers, etc.
URLENCODE() URL parameters Query strings, paths

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 Salesforce Secure Coding Guide, CSRF protection is automatically enabled:

Known Vulnerability: Page Load DML

Critical: CSRF protection has a brief vulnerability window during page load. Never perform DML operations in constructors or initialization methods.

// 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/v59.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

Data Type Encryption Available
Standard and Custom Fields Text, Text Area, Long Text Area, Email, Phone, URL, Date, DateTime
Files and Attachments All files, attachments, and Salesforce Files
Search Index Index entries for encrypted fields
Chatter Posts, comments, questions, answers

Step-by-Step: Enable Shield Encryption

1

Enable Shield Platform Encryption

SetupPlatform EncryptionEncryption Policy → Enable

2

Generate Tenant Secret

Key ManagementGenerate Tenant Secret → Choose type (Data, Files, Search Index)

3

Select Fields to Encrypt

Encryption PolicyEncrypt Fields → Select objects and fields → Save

4

Enable File Encryption

Encryption PolicyEncrypt Files and Attachments → Enable

Important Considerations:

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

SetupLogin 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

SetupView Setup Audit Trail → Last 20,000 configuration changes (180 days via CSV)

-- 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:

Event Type What It Tracks Security Use Case
Login Event All login attempts (success/failure) Detect brute force, unusual locations
API Event All API calls with details Detect bulk data extraction
Report Export Report downloads and exports Detect data exfiltration
Permission Changes Permission set/profile changes Detect privilege escalation
URI Event All page views with timing Usage patterns, performance

Setting Up Real-Time Alerts

1

Create Transaction Security Policy

SetupTransaction SecurityNew Policy

2

Define Trigger Conditions

Example: Alert when API requests exceed 1000/hour from single user

3

Set Actions

Choose: Block, Multi-Factor Authentication Required, or Notify

// Custom Apex policy for suspicious API activity
global class HighVolumeAPIPolicy implements TxnSecurity.PolicyCondition {
    public boolean evaluate(TxnSecurity.Event e) {
        // Trigger if more than 500 API calls in 10 minutes
        Integer recentCalls = [
            SELECT COUNT() FROM ApiEvent
            WHERE UserId = :e.getUserId()
            AND EventDate > :DateTime.now().addMinutes(-10)
        ];
        return recentCalls > 500;
    }
}

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

Attack Type How It Works Defense
Vishing (Voice Phishing) Attacker calls claiming to be Salesforce support, asks to install "diagnostic tool" Verify through official channels, never install unsolicited software
Fake OAuth Consent Attacker sends OAuth authorization link for malicious app Admin-only app approval, user training
Credential Phishing Fake Salesforce login page captures username/password MFA, check URL, security awareness training
Pretexting Attacker creates elaborate scenario to gain trust before requesting access Verify identity through known contacts, follow procedures

Security Awareness Training Checklist

Salesforce will NEVER call unsolicited: If someone claims to be from Salesforce, hang up and call official support
Never install software from phone requests: All software installations should go through IT
Verify OAuth app requests: Contact your Salesforce admin before authorizing any new app
Check login URLs carefully: Should always be login.salesforce.com or your My Domain
Report suspicious contacts: Forward phishing emails to security team, report calls
Never share MFA codes: Legitimate support will never ask for your authentication codes

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 - they bypass all Salesforce security controls (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.

Critical Warning: In December 2024, a massive supply chain attack compromised 35+ Chrome extensions affecting 3.7 million users. Attackers phished developer accounts and pushed malicious updates that stole cookies, session tokens, and credentials. The attack continued into 2025, with GitLab's Threat Intelligence team identifying additional compromised extensions in February 2025. Even legitimate extensions with excessive permissions can be exploited if compromised.

How Chrome Extensions Can Compromise Salesforce Security

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

Attack Vector How It Works Impact
Session Hijacking Extension reads Salesforce session cookies (sid) and forwards them to attacker's server Complete account takeover without needing credentials
Credential Harvesting Keylogger functionality captures username/password on login pages Attacker obtains reusable credentials for future access
DOM Manipulation Extension modifies Salesforce pages to inject fake forms or redirect data Users unknowingly submit sensitive data to attackers
API Token Theft Extension intercepts OAuth tokens from browser storage or network requests Persistent API access even after password changes
Data Exfiltration Extension reads and copies data from Salesforce pages in real-time Continuous data theft without triggering API limits
Supply Chain Attack Legitimate extension gets sold or hacked, malicious update pushed to all users Mass compromise of previously trusted extension users

Why Extensions Are Invisible to Salesforce Security Controls

Unlike Connected Apps that use OAuth and appear in Salesforce's security dashboards, browser extensions operate completely outside Salesforce's visibility. This makes them exceptionally dangerous and difficult to detect.

The Invisible Threat: Browser extensions piggyback on your existing authenticated browser session. They don't need their own OAuth token or API credentials - they simply inherit YOUR permissions and act as YOU. Salesforce cannot distinguish between actions you take and actions an extension takes on your behalf.

Security Control OAuth Connected Apps Browser Extensions
Visible in Setup → Connected Apps ✓ Yes - Listed and manageable ✗ No - Completely invisible
Appears in OAuth Usage Report ✓ Yes - Token grants tracked ✗ No - Uses session cookie, not OAuth
Admin Can Revoke Access ✓ Yes - Revoke tokens anytime ✗ No - No Salesforce control
Login History Attribution ✓ Yes - Shows app name ✗ No - Appears as normal user session
API Limits Apply ✓ Yes - Counted against limits ✗ Partial - DOM scraping bypasses API entirely
Setup Audit Trail Logging ✓ Yes - App authorization logged ✗ No - No installation record in Salesforce
Event Monitoring Detection ✓ Yes - API events captured ✗ Limited - Only if extension makes API calls
Can Block at Org Level ✓ Yes - Blocklist apps ✗ No - Requires endpoint/browser management

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 (Invisible to 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 user's full permissions → NO TRACE in Salesforce

// 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/v59.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
    // Zero API calls = Zero detection in Event Monitoring
    exfiltrateToAttacker(row.innerText);
});

Key Insight: When you review "Connected Apps OAuth Usage" in Setup, you might feel secure seeing only approved applications. But browser extensions don't appear there at all. A malicious extension could be exfiltrating your entire org's data right now, and there would be no record of it in any Salesforce report. The only way to detect and control extensions is through endpoint management tools outside of Salesforce.

Real-World Extension Attack Scenarios

Scenario 1 - The "Helpful" Productivity Extension: An employee installs a popular Salesforce productivity extension from the Chrome Web Store. The extension legitimately enhances their workflow, but also silently captures every record they view and sends it to an external server. Because the extension has broad permissions to "read and change all your data on salesforce.com," this behavior appears normal to security scanners.

Scenario 2 - The Compromised Update: A trusted extension used by 50,000 Salesforce users is acquired by a new company. The new owner pushes an update that adds telemetry code, which actually harvests session tokens. Within hours, thousands of Salesforce orgs are compromised before anyone notices.

Scenario 3 - The Fake Extension: Attackers create a Chrome extension with a name similar to a popular Salesforce tool (e.g., "Salesforce Inspector Pro" vs legitimate "Salesforce Inspector"). Users install the fake version, which looks identical but contains malicious code.

Dangerous Extension Permissions to Watch For

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

CRITICAL
cookies
Can read Salesforce session cookies (sid) and hijack your authenticated session
Impact: Complete account takeover
CRITICAL
<all_urls>
Grants access to ALL websites you visit, including all Salesforce pages
Impact: Universal data access
HIGH
webRequest
Can intercept and read all network traffic including API calls and data transfers
Impact: Data interception
HIGH
webRequestBlocking
Can modify requests in transit - alter data being sent to Salesforce servers
Impact: Data manipulation
MEDIUM
tabs
Can see all open tabs including Salesforce URLs and page titles
Impact: Activity monitoring
MEDIUM
storage
Can store captured data locally and exfiltrate when ready
Impact: Data staging
MEDIUM
clipboardRead
Can read anything you copy - passwords, sensitive data, record IDs
Impact: Credential theft
MEDIUM
history
Can see your complete browsing history including all Salesforce pages visited
Impact: Behavior tracking

Host Permissions - Salesforce Targeting

Extensions requesting these host permissions have direct access to your Salesforce org:

manifest.json - DANGEROUS HOST PERMISSIONS
{
  "host_permissions": [
    "*://*.salesforce.com/*",        // All Salesforce domains
    "*://*.force.com/*",             // Visualforce & custom domains
    "*://*.lightning.force.com/*",   // Lightning Experience
    "*://*.my.salesforce.com/*",     // My Domain URLs
    "*://*.cloudforce.com/*"         // Sandbox environments
  ]
}

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

Implement Browser Extension Allowlisting: Use Chrome Enterprise policies to allow only pre-approved extensions. Block all others by default.
Deploy Endpoint Detection: Use EDR solutions that monitor browser extension behavior for suspicious activity like unusual network connections.
Require Dedicated Browser Profiles: Create a separate Chrome profile for Salesforce access with no extensions installed.
Enable Login IP Restrictions: Even if sessions are stolen, IP restrictions can prevent access from attacker locations.
Monitor Connected App OAuth Activity: Extensions often use OAuth; review and revoke suspicious app authorizations regularly.
Implement Session Security Settings: Lock sessions to IP, enable HTTPS, reduce session timeout to minimize exposure window.

Chrome Enterprise Policy Configuration

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

Block by Default
ExtensionInstallBlocklist
Deny all extensions unless explicitly approved
Allowlist Only
ExtensionInstallAllowlist
Whitelist specific vetted extensions by ID
Force Install
ExtensionInstallForcelist
Auto-install required security extensions
Host Protection
RuntimeBlockedHosts
Block extension access to Salesforce domains
Chrome Enterprise Policy
policy.json
{
  "ExtensionInstallBlocklist": ["*"],
  // ↑ Block ALL extensions by default (zero-trust approach)

  "ExtensionInstallAllowlist": [
    "eimadpbcbfnmbkopoojfekhnkhdbieeh",  // Dark Reader
    "cjpalhdlnbpafiamejdnhcphjbkeiagm",  // uBlock Origin
    "hdokiejnpimakedhajhdlcegeplioahd"   // LastPass
  ],
  // ↑ Only these extension IDs can be installed

  "ExtensionInstallForcelist": [
    "your-security-ext-id;https://your-domain.com/update.xml"
  ],
  // ↑ Auto-install corporate security extensions

  "ExtensionAllowedTypes": ["extension", "theme"],
  // ↑ Only allow extensions and themes (no hosted apps)

  "RuntimeBlockedHosts": [
    "*://*.salesforce.com/*",
    "*://*.force.com/*",
    "*://*.lightning.force.com/*",
    "*://*.my.salesforce.com/*"
  ]
  // ↑ Even allowed extensions CANNOT access Salesforce
}
Deploy via Google Admin Console → Devices → Chrome → Settings

Pro Tip: Use RuntimeBlockedHosts as a safety net - even if an extension is accidentally approved, it still cannot access your Salesforce domains. This provides defense-in-depth protection.

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

Evaluation Criteria Safe Indicator Red Flag
Publisher Known company, verified badge, official website Unknown publisher, no verification, no web presence
User Base 10,000+ users, consistent growth over time Few users, sudden spike in installs
Reviews Detailed reviews, mix of positive/critical, verified users Generic praise, all 5-stars, review dates clustered
Permissions Minimal permissions matching stated functionality Excessive permissions, access to all sites
Update History Regular updates, changelog provided No updates for years OR recent ownership change
Source Code Open source, code available for review Obfuscated code, closed source for sensitive features

Incident Response: If You Suspect Extension Compromise

1

Immediate Isolation

Disable the suspected extension immediately. Do not uninstall yet - forensics may need it.

2

Revoke All Sessions

In Salesforce: Setup → Session Management → Log out all users. Force password resets.

3

Review OAuth Tokens

Check OAuth Usage report and revoke any suspicious connected app authorizations.

4

Audit Recent Activity

Review Login History, Setup Audit Trail, and Event Monitoring logs for anomalies.

5

Notify Security Team

Report to your security team and consider engaging Salesforce support for guidance.

Best Practice: The safest approach for high-security environments is to access Salesforce from a browser with ZERO extensions installed. Create a dedicated Chrome profile or use a managed browser specifically for Salesforce access.

15 Complete Security Checklist

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

Authentication & Access (Priority: Critical)

MFA enabled for all users - No exceptions, including API users if possible
Health Check score 80+ - Fix all high-risk and medium-risk issues
Session timeout 2 hours or less - Shorter for sensitive data access
Password policy enforced - 12+ chars, complexity, 90-day expiry
Login IP restrictions - At minimum for admin profiles

Permissions & Data Access (Priority: High)

Audit Modify All Data permission - Should be System Admin only
Review View All Data permission - Limit to necessary roles
Remove unused permission sets - Delete orphaned sets
FLS configured for sensitive fields - SSN, credit card, health data
Sharing rules reviewed - Ensure no unintended data exposure

Connected Apps & Integrations (Priority: Critical)

Block unknown Connected Apps - Review OAuth Usage monthly
Admin approval required for apps - No user self-authorization
Dedicated integration users - One per integration, minimum permissions
Token expiration configured - 90 days max, enable rotation
Unused integrations removed - Audit annually

Browser Extension Security (Priority: Critical)

Extension allowlist policy implemented - Use Chrome Enterprise to block unapproved extensions (See Section 14)
Dedicated browser profile for Salesforce - Zero extensions installed in Salesforce-only profile
User training on extension risks - Employees understand extensions bypass Salesforce security controls
Endpoint monitoring for extensions - EDR/MDM tracks browser extension installations
Extension audit conducted quarterly - Review all installed Salesforce-related extensions across endpoints
Incident response plan includes extensions - Know steps if malicious extension suspected

Code Security (Priority: High)

No SOQL injection vulnerabilities - Use bind variables or escapeSingleQuotes
FLS enforced in Apex - Use USER_MODE or SECURITY_ENFORCED
XSS prevention - Use encoding functions, avoid innerHTML
No DML in constructors - Prevent CSRF vulnerabilities
Security review for AppExchange apps - Pass Salesforce security review

Monitoring & Response (Priority: Medium)

Review login history weekly - Look for unusual patterns
Setup Audit Trail monitored - Alert on critical changes
Event Monitoring enabled - If Shield license available
Incident response plan documented - Know who to contact, steps to take
Security training conducted - Annual for all users

Final Recommendation: Security is an ongoing process, not a one-time task. Schedule quarterly security reviews, stay updated on Salesforce Security Advisories, and foster a security-conscious culture in your organization.

Link copied to clipboard!
Previous Post
OmniScript Debugging Methods
Next Post
Salesforce Packaging Options – A Comprehensive Guide for Enterprise Development
Archives by Year
2025 16 2024 2 2023 9 2022 8 2021 4 2020 18 2019 16 2018 21 2017 34 2016 44 2015 54 2014 30 2013 31 2012 46 2011 114 2010 162
Search Blog

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Jitendra Zaa

Subscribe now to keep reading and get access to the full archive.

Continue Reading