Salesforce CORS, CSP & ConnectedApp save the day!

Salesforce CORS, CSP & ConnectedApp save the day!

Let's Understand how CORS,CSP & ConnectedApp gels together for a Secure org??

As a part of SiteReliability engineering team(Or Sr Administrator/Lead), security is always top of mind of admins—especially when it comes to integrations. One topic that could easily get overlooked is CORS (Cross-Origin Resource Sharing). It’s a small setting but can make or break your org’s security.

What is CORS in Salesforce?

CORS controls which external web applications can make API requests to your Salesforce org from a browser. Think of it as a security gatekeeper—without CORS, web-based apps (like SPAs, PWAs) would be blocked from fetching data from Salesforce due to browser security policies.

??? How does it work?

  • You specify trusted domains under Setup → CORS
  • Only these domains can make JavaScript-based API calls to Salesforce
  • This ensures your data isn’t exposed to unauthorized web apps

?? When Do You Need CORS?

? Use CORS if: 1?? You’re building a Salesforce Experience Cloud Site with LWC or Aura that needs to fetch records using REST APIs.

2?? A Salesforce Lightning Web Component (LWC) in a third-party app needs to query data from your Salesforce org.

3?? A Heroku-hosted web app is embedding Salesforce data dynamically.

?? Example: A partner portal built on Salesforce Experience Cloud (LWR template) needs to fetch a list of Opportunities from Salesforce using JavaScript-based API calls. If CORS is not enabled, the browser will block these requests.

? When CORS is NOT Needed

?? Apex Callouts to External APIs: If your Apex code makes an HTTP request (HttpRequest) to an external system, CORS does not apply—Apex is server-side, not browser-based.

?? Salesforce-to-Salesforce Integrations: If your integration uses Salesforce Connect, External Services, or Named Credentials, CORS is irrelevant since these run on Salesforce servers.

?? Middleware-Based Integrations: If Salesforce integrates via MuleSoft, Boomi, or an AWS Lambda function, the API calls originate from a backend server, not a browser, so CORS isn’t needed.

?? Example: A MuleSoft integration syncs Opportunities from Salesforce to an external database. Since MuleSoft makes the API call from its own servers, CORS is not a factor.

?? Why Connected Apps Are Essential

Even if CORS is enabled, OAuth-based authentication is required to ensure secure access. This is where Connected Apps come in:

?? OAuth ensures only authorized apps get API access

?? Granular control over API scopes (read-only, full access, etc.)

?? Session security & token-based authentication (instead of exposing Session IDs)

?? Action Item: Always use a Connected App with OAuth for secure API authentication. Never expose API calls using unrestricted CORS settings!

A brief explanation to this as follow on Key settings:

1?? OAuth Settings (Mandatory for Secure API Access)

  • ? Enable OAuth Settings
  • ? Callback URL → Must match the redirect URI of your web app
  • ? Selected OAuth Scopes →?? Full Access (not recommended unless necessary)?? Perform requests on your behalf at any time (refresh_token, offline_access)?? Access and manage your data (api)

?? Example: A React Single Page App (SPA) authenticating via OAuth 2.0 Web Server Flow should have a callback URL like: ?? https://app.example.com/callback

2?? CORS Settings (Setup → CORS in Salesforce)

  • ? Add the frontend app’s domain
  • ? Only allow trusted domains (avoid * wildcard!)

?? Example: A Vue.js app on https://portal.example.com making API calls needs this domain added to CORS Trusted Origins.

3?? Permitted Users & IP Restrictions (Security Controls)

  • ? Restrict to Admin Approved Users (recommended)
  • ? IP Relaxation: Set to "Enforce IP Restrictions" if using corporate networks
  • ? Session Policies: Set timeout & token expiration

?? Example: For an Angular-based Partner Portal, limit access to only partner users via profile permissions in the Connected App.

4?? Token Expiration & Refresh (To Avoid Frequent Logins)

  • ? Set refresh token expiration based on org policy
  • ? Use refresh_token scope to allow silent authentication

?? Example: A Progressive Web App (PWA) syncing Salesforce data every 30 minutes needs a long-lived refresh token to avoid forcing users to re-authenticate.

Now, As we took approach above on How CORS & ConnectedApp are important together, here comes somewhat trickier part to the equation. For this, Let's understand CORS vs. CSP – What’s the Difference? And Why Do They Matter Together?

Even though CSP (Content Security Policy) and CORS serve different purposes, they work together to secure your Salesforce org.

Here's how CORS comes in play by itself:

CORS's (Cross-Origin Resource Sharing) objective is to Controls which external domains can make API requests to Salesforce

Applies to: API requests made from a browser (JavaScript-based)

Use Case: Allowing JavaScript-based external apps (SPAs, PWAs) to access Salesforce APIs

Configuration in Salesforce: Setup → CORS

Here's how CSP comes in play by itself:

CSP's (Content Security Policy) objective is to Control what types of content (scripts, styles, iframes) a Salesforce page can load

Applies to: Web pages, Experience Cloud sites, Lightning Web Components (LWC)

Use Case: Preventing XSS (Cross-Site Scripting), data injection attacks, and malicious script execution

Configuration in Salesforce: Setup → CSP Trusted Sites

**Now this brings me to next question WHEN to enlist CSP under Setup and in Site's CSP Settings??

When you configure CSP Trusted Sites in Setup, it applies to your entire Salesforce org. This is useful when:

? LWCs or Visualforce pages inside Salesforce need to load external scripts (e.g., Google Fonts, third-party analytics).

? API calls from JavaScript in a Lightning component require external resource access.

? Embedded iframes or remote content need to be explicitly allowed in Salesforce pages.

?? Example: If an LWC inside Salesforce loads a JavaScript library from https://cdn.example.com, you must add this domain to CSP Trusted Sites in Setup.

**If your Experience Cloud site (formerly Community) embeds external content specific to that site, you might need to whitelist the domain inside the Site Builder settings.

This is useful when:

? A specific Experience Cloud site loads external fonts, scripts, or videos.

? Only one site needs access to an external service (instead of allowing it org-wide).

?? Example: You have two Experience Cloud sites:

1?? Partner Portal (loads an embedded YouTube video)

2?? Customer Support Portal (does NOT need YouTube)

Instead of allowing https://www.youtube.com for the whole org, you can whitelist it only in the Partner Portal’s CSP settings under Site Configuration.

?? Here's how CORS & CSP comes in play together:

?? Scenario 1: A Custom Lightning Web Component (LWC) Fetches Data from an External App

  • You allow the external app’s domain in CSP Trusted Sites (so it can load safely in your LWC).
  • You configure CORS settings to allow that app to make API calls back to Salesforce.
  • ?? Why? This ensures both secure API access (CORS) and prevents unauthorized script execution (CSP).

?? Scenario 2: A Salesforce Experience Cloud Site Embeds an External Web App

  • You enable CORS so that the external web app can fetch Salesforce data.
  • You configure CSP to ensure only trusted scripts/styles load inside your Experience Cloud pages. ?? Why? This prevents unauthorized content injection and API misuse.

?? Important to know, When CSP is NOT Required???

If the integration is ONLY making API calls and NOT embedding scripts, styles, or iframes, CSP is not needed.

?? Security Alert: Lower Environments & CORS Risks

?? Imagine a hardcoding sandbox link (https://mydevinstance--sandbox.my.salesforce.com) into code. Upon code being deployed to production without updating the CORS settings, your production API could be exposed to unauthorized domains!

BUT, Let's not haste through to make judgement but try to understand more on impact.

Hardcoded sandbox URL in production

Any HardCoded URL Risk: ? Only sandbox data accessed

CORS Risk: ? No production exposure

Prod Data at Risk: Not an issue if CORS isn't open to sandbox

Sandbox URL whitelisted in production CORS

Any HardCoded URL Risk: ? Still points to sandbox

CORS Risk: ? Attackers can misuse API access

Prod Data at Risk: ?? Production data at risk if API requests can be modified

Sandbox & Production both exposed via CORS

Any HardCoded URL Risk?: ? If URLs are static

CORS Risk: ? Browser allows cross-origin calls

Prod Data at Risk: ?? Critical risk if tokens can be stolen & reused

Ways to Monitor:

After all, the above basic understanding to auditing & monitoring comes in a fantastic match. (It's like Tea to ParleG(Indian Cookies)!! Sorry i'm just thinking about to make some for me at this point in time at my end)

1?? Use Event Monitoring (API Calls & Security Analysis)

?? Best for: Detecting suspicious API usage trends

? Navigate to: Setup → Event Monitoring ? Check the API Event log for unusual spikes in API calls ? Use Transaction Security Policies to flag/block specific API patterns

?? Example: If a single external IP suddenly makes thousands of API requests, it could be a data scraping attempt.

?? Salesforce Shield - download event logs via Event Monitoring API for deeper analysis.

?? 2?? View API Usage in Setup

?? Best for: Quick overview of API consumption

? Navigate to: Setup → System Overview ? Look for unexpected API spikes under "API Usage"

?? Example: A Connected App configured with CORS suddenly starts consuming excessive API calls. This could indicate a compromised access token.

?? 3?? Monitor Connected App Access Logs

?? Best for: Tracking API authentication attempts

? Navigate to: Setup → Connected Apps OAuth Usage ? Check the list of apps accessing Salesforce ? Monitor the "Last Used Date" for unexpected activity

?? Example: A sandbox environment URL is still whitelisted in CORS settings, allowing a decommissioned app to make API calls.

?? 4?? Set Up Health Check Alerts

?? Best for: Automating security monitoring

? Navigate to: Setup → Health Check ? Enable alerts for high-risk security settings

?? Example: An unexpectedly relaxed session timeout policy could indicate a misconfiguration that exposes your OAuth tokens to theft.

?? 5?? Leverage Security Center for Real-Time Alerts (If Using Salesforce Shield)

?? Best for: Enterprise-level security monitoring

? Set up dashboards to detect failed login attempts & high API usage ? Create alerts for unauthorized API calls from unknown IPs

?? Example: A user in an unusual geographic location starts making mass API requests—this could indicate a compromised account.

Now we understood How CORS/CSP and ConnecedApp(assuming already known to Admins) work in harmony, here is brief Actionable Steps to Secure Your Salesforce Org

?? Enable CORS only for trusted domains—never use a * wildcard!

?? Use a Connected App with OAuth for authentication.

?? Combine CORS with CSP (Content Security Policy) to prevent XSS risks.

?? Audit & remove unnecessary lower-environment links before go-live.

?? Monitor API logs to detect unauthorized access attempts.

Salesforce security isn’t just an IT responsibility—it’s a shared responsibility for admins, but mainly comes on the solid shoulders if architects, developers, QAs, ProgramManagers. If you're working with integrations, take a moment today to review your org’s CORS settings!

Have you ever encountered security issues related to CORS in Salesforce? Let’s discuss in the comments! ????

#SalesforceAdministrators #SalesforceDev #Debugging #SalesofrceTips #ProactiveAdmin

?

要查看或添加评论,请登录

Gaurav Jain的更多文章

社区洞察

其他会员也浏览了