Home / security / network-security-and-trusted-ips

network-security-and-trusted-ips

Configure and audit Salesforce network security controls — trusted IP ranges (org-wide Network Access), login IP ranges on profiles, CSP Trusted Sites for Lightning components, CORS allowlists for external JavaScript, and TLS requirements — and troubleshoot login-blocked-by-IP or CSP violation errors. NOT for per-profile login IP range policy, IP relaxation decisions, or their interaction with MFA and SSO — use security/ip-relaxation-and-restriction.

• v1.0.0
• Salesforce Spring '25+
• Updated 2026-04-04
• Security

• trusted-ip-ranges
• network-access
• csp-trusted-sites
• cors
• login-ip-ranges
• lightning-security

Open the skill folder on GitHub

Network Security and Trusted IPs

This skill activates when a practitioner needs to configure, audit, or troubleshoot Salesforce network-layer security controls: org-wide Trusted IP Ranges, profile-level Login IP Ranges, CSP Trusted Sites for Lightning components, CORS allowlists for external API callers, and My Domain TLS requirements. It covers all three operational modes — configuring from scratch, auditing existing restrictions, and diagnosing login failures or CSP violations caused by network controls.

Before Starting

Gather this context before working on anything in this domain:

• Trusted IP Ranges vs. Login IP Ranges are different controls with different scopes — Trusted IP Ranges (Setup > Security > Network Access) apply org-wide and bypass the email verification challenge when logging in. Login IP Ranges on profiles enforce hard IP-based login restrictions for users on that profile — logins from outside the range are denied entirely. Conflating the two is the most common misconfiguration.
• CSP Trusted Sites and CORS are separate allow-lists — CSP Trusted Sites govern what external content Lightning pages can load (fonts, scripts, images, iframes). CORS governs which external domains can send JavaScript requests to the Salesforce REST, SOAP, and Bulk APIs. A domain can be in one list but not the other.
• My Domain is a prerequisite for most Lightning security controls — CSP Trusted Sites, CORS, and Lightning Experience itself require My Domain to be deployed. Confirm My Domain is deployed before attempting to configure these.
• Sandbox IP restrictions do not carry over from production after a full sandbox refresh — All Network Access and profile Login IP Ranges must be re-entered manually after a sandbox refresh. Document them before refreshing.
• TLS 1.2+ is mandatory — Salesforce enforces TLS 1.2 as the minimum for all inbound and outbound connections. Any external system calling Salesforce or being called by Salesforce must support TLS 1.2 or higher.

Core Concepts

Concept 1 — Trusted IP Ranges (Org-Wide Network Access)

Location: Setup > Security > Network Access

Trusted IP Ranges define a set of IP addresses or CIDR blocks that Salesforce considers trusted for all users in the org. When a user logs in from a trusted IP:

• Salesforce skips the email verification challenge that would otherwise be required when logging in from an unrecognized device or location.
• MFA is not bypassed — if MFA is enforced, it is still required even from a trusted IP. Trusted IPs only bypass the email verification step, not MFA.
• Trusted IP Ranges are purely about skipping the email challenge, not about restricting access.

Configuration: Setup > Security > Network Access > New. Provide a Start IP Address and End IP Address. IPv4 ranges are expressed as start/end pairs (e.g., 203.0.113.10 to 203.0.113.254). IPv6 is supported but must be entered in full expanded form — CIDR notation is not accepted directly in the UI for IPv6.

Limit: Salesforce does not publish a hard maximum for the number of trusted IP entries per org, but keep the list to the minimum needed for operational coverage.

Concept 2 — Login IP Ranges on Profiles

Location: Setup > Profiles > [Profile Name] > Login IP Ranges

Login IP Ranges are a profile-level hard restriction. Users on that profile cannot log in at all from an IP outside the configured range — they receive an error, not just an email challenge. This is the appropriate control for locking privileged profiles (e.g., System Administrator) to known office or VPN IP blocks.

Key distinctions from Trusted IP Ranges:

Important: If a profile has Login IP Ranges set and a user on that profile attempts to log in from outside those ranges, the login is denied with Status = 'No Salesforce.com Access' in LoginHistory. There is no email challenge fallback.

Concept 3 — CSP Trusted Sites for Lightning Components

Location: Setup > CSP Trusted Sites

Salesforce Lightning Experience enforces a Content Security Policy (CSP) that restricts what external resources can be loaded in Lightning pages. By default, Lightning blocks all external script-src, img-src, frame-src, font-src, connect-src, and style-src origins not already on Salesforce's internal allowlist.

When a Lightning component (LWC or Aura) loads an external resource — a CDN-hosted JS library, an external image, a web font, or a third-party iframe — the browser will block it with a CSP violation unless the source domain is added to the CSP Trusted Sites list.

Each CSP Trusted Site entry specifies:

• Site Name — a human-readable label
• Site URL — the origin (e.g., https://cdn.example.com)
• CSP Directives — which directives the entry applies to: connect-src, font-src, frame-src, img-src, media-src, object-src, script-src, style-src, or worker-src

Scope: CSP Trusted Sites apply to all Lightning pages in the org. There is no profile-level or component-level scoping — adding an entry allows that resource org-wide in Lightning.

Concept 4 — CORS Allowlist

Location: Setup > CORS

Cross-Origin Resource Sharing (CORS) governs which external web application origins are allowed to make JavaScript-initiated HTTP requests to Salesforce REST, SOAP, Bulk, and streaming APIs. This is relevant when a third-party web application (not hosted on Salesforce) makes API calls directly from the browser using JavaScript.

A CORS entry requires:

• Origin URL Pattern — the full origin of the external site, e.g., https://app.example.com. Wildcard subdomains are supported with *.example.com.

Without a CORS entry, the browser's preflight OPTIONS request will be denied and the API call will fail with a CORS error. Note: CORS only applies to browser-initiated calls — server-to-server API calls (cURL, Apex callouts, integration middleware) are not subject to CORS and do not need entries here.

Common Patterns

Mode 1: Configuring Network Security Controls from Scratch

When to use: A new org is being hardened pre-go-live, or an existing org has never had explicit network restrictions configured.

How it works:

1. Identify IP requirements. Collect the office IP ranges, VPN exit nodes, and any CI/CD pipeline IP blocks that need to be trusted or restricted.
2. Configure org-wide Trusted IP Ranges (skips email challenge for all users):
   • Setup > Security > Network Access > New
   • Enter Start IP and End IP for each range (one entry per range)
   • Repeat for each office location and VPN exit IP block
3. Configure Login IP Ranges on privileged profiles (hard restrict by IP):
   • Setup > Profiles > System Administrator > Login IP Ranges > New
   • Enter Start IP and End IP for each allowed range
   • Repeat for any other privileged profiles (e.g., custom admin profiles)
   • Test from a known-good IP before saving, to avoid locking out your own session
4. Configure CSP Trusted Sites for any external resources in Lightning:
   • Setup > CSP Trusted Sites > New
   • Enter the origin URL (e.g., https://cdn.jsdelivr.net)
   • Select the applicable CSP directives (most CDN JS libraries need script-src and connect-src)
5. Configure CORS if any external web applications call the Salesforce API from a browser:
   • Setup > CORS > New
   • Enter the exact origin URL (e.g., https://portal.example.com)
6. Verify My Domain is deployed: Setup > My Domain. Lightning security controls require My Domain.

Why not rely on org-wide trusted IPs alone for admin lockdown: Trusted IP Ranges bypass the email challenge but do not prevent logins from outside those IPs. Only Login IP Ranges on profiles provide hard login denial.

Mode 2: Auditing Existing Network Security Configuration

When to use: Pre-go-live review, post-incident investigation, or compliance audit requiring a full inventory of network restrictions.

How it works:

1. Export Trusted IP Ranges: Setup > Security > Network Access. Review for stale ranges, overly broad CIDR blocks, or documentation gaps.
2. Export Login IP Ranges per profile: For each profile with sensitive access (System Administrator, custom admin), review Setup > Profiles > [Profile] > Login IP Ranges. Check that every range is documented and intentional.
3. Export CSP Trusted Sites: Setup > CSP Trusted Sites. Flag any script-src entries pointing to non-authoritative domains or entries added without a documented justification.
4. Export CORS entries: Setup > CORS. Verify each origin is still an active application and that wildcard entries are justified.
5. Cross-reference with LoginHistory for Status = 'No Salesforce.com Access' entries — these indicate users who were denied login due to IP restrictions. Unexpected denials may indicate a range misconfiguration.

   SELECT UserId, LoginTime, SourceIp, Status, LoginType
   FROM LoginHistory
   WHERE Status = 'No Salesforce.com Access'
     AND LoginTime >= LAST_N_DAYS:30
   ORDER BY LoginTime DESC
   LIMIT 500

6. Document findings in the work template, noting any gaps, over-broad ranges, or undocumented entries.

Mode 3: Troubleshooting Login Blocked by IP or CSP Violations

When to use: A user reports they cannot log in, or a Lightning component is failing to load external resources.

How it works — Login IP restriction troubleshooting:

1. Check the user's profile: Setup > Users > [User] > Profile. Navigate to that profile's Login IP Ranges.
2. Confirm the user's current IP (ask them to visit whatismyip.com or check the SourceIp field in LoginHistory).
3. If their IP is outside the configured ranges, either add a new range entry or move the user to a profile without Login IP Ranges.
4. Check LoginHistory to confirm the denial:

   SELECT LoginTime, SourceIp, Status, LoginType
   FROM LoginHistory
   WHERE UserId = '005XXXXXXXXXXXXXXX'
   ORDER BY LoginTime DESC
   LIMIT 20

5. For org-wide Trusted IP Range additions (to stop email verification challenges), add the IP range under Setup > Security > Network Access.

How it works — CSP violation troubleshooting:

1. Open the browser Developer Tools (F12) > Console tab. CSP violations appear as red errors beginning with Content Security Policy.
2. Identify the blocked origin from the error message (e.g., Refused to load script from 'https://cdn.example.com/...').
3. Navigate to Setup > CSP Trusted Sites > New.
4. Enter the blocked origin URL and select the appropriate directives based on the resource type:
   • External JS files → script-src
   • API calls from JS → connect-src
   • External CSS → style-src
   • Web fonts → font-src
   • Embedded iframes → frame-src
   • Images → img-src
5. Save and reload the Lightning page. The browser cache may need clearing.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner activating this skill:

1. Gather context — confirm the org edition, relevant objects, and current configuration state
2. Review official sources — check the references in this skill's well-architected.md before making changes
3. Implement or advise — apply the patterns from Core Concepts and Common Patterns sections above
4. Validate — run the skill's checker script and verify against the Review Checklist below
5. Document — record any deviations from standard patterns and update the template if needed

Review Checklist

Run through these before marking work in this area complete:

• [ ] Confirmed distinction between Trusted IP Ranges (email challenge bypass) and Login IP Ranges (hard login denial) — applied the correct one for the use case
• [ ] Login IP Ranges on privileged profiles tested from a known-good IP before saving, to avoid self-lockout
• [ ] CSP Trusted Sites entries use the minimum set of directives needed (not all directives for every entry)
• [ ] CORS entries use exact origin URLs; wildcard entries documented and justified
• [ ] My Domain is deployed (required for CSP Trusted Sites and Lightning Experience)
• [ ] Sandbox network access configuration documented separately — it will be lost on full refresh
• [ ] LoginHistory queried for Status = 'No Salesforce.com Access' to confirm no unintended login denials
• [ ] TLS 1.2+ confirmed for any external systems in CORS or CSP entries

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Trusted IP Ranges do not prevent logins from untrusted IPs — they only skip the email challenge — Many practitioners configure Trusted IP Ranges expecting them to restrict logins to those IPs. They do not. A user outside a Trusted IP range still logs in successfully; they just receive an email verification challenge first. To actually restrict login to specific IPs, use Login IP Ranges on the user's profile.
2. Login IP Ranges on a profile lock out all users on that profile, including System Administrators — If you configure Login IP Ranges on the System Administrator profile and your own IP is not in the range, you will be locked out of your own session on next login. Always test from a confirmed IP-in-range browser session before saving profile-level IP restrictions.
3. CSP Trusted Sites scope is org-wide — there is no component-level or profile-level scoping — Adding a CSP Trusted Site entry for a domain allows that resource to be loaded anywhere in Lightning for any user in the org. There is no way to restrict a CSP entry to specific pages, components, or user profiles.

Output Artifacts

Related Skills

• login-forensics — Use when investigating who was denied login due to IP restrictions, or to reconstruct login timelines for a specific user
• org-setup-and-configuration — Use for MFA configuration, session timeout settings, and My Domain deployment
• transaction-security-policies — Use when you need real-time dynamic enforcement (e.g., block login from a country) rather than static IP allowlists
• event-monitoring — Use when you need to stream real-time login events or download bulk EventLogFile login logs for SIEM ingestion

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/well-architected.md
• templates/network-security-and-trusted-ips-template.md
• scripts/check_network_security_and_trusted_ips.py