Cross-Origin Resource Sharing (CORS) allows web browsers to request
resources from other origins. For example, using CORS, the JavaScript for a web application at
https://www.example.com can request a resource from
https://www.salesforce.com. To allow access to supported Salesforce APIs,
Apex REST resources, and Lightning Out from JavaScript code in a web browser, add the requesting
origin to your Salesforce CORS allowlist. For Lightning apps that allow web browsers to make
requests from their orgs, CORS allowlist prevents requests to Lightning apps unless the request
comes from an approved URL. The allowlist is in effect for your My Domain URL and api.salesforce.com.
Required Editions
| Available in: Salesforce Classic and
Lightning Experience |
| Available in: Developer, Enterprise, Performance, and
Unlimited Editions
|
| Available with API access enabled in: Professional Edition |
| User Permissions Needed |
| To create, read, update, and delete: |
Modify All Data |
These Salesforce technologies in your org support CORS.
- Apex REST
- Bulk API
- Bulk API 2.0
- Connect REST API
- Lightning Out
- REST API
- CRM Analytics REST API
- User Interface API
Add an origin serving the request code to the CORS allowlist. If a browser that supports CORS
makes a request to an origin in the allowlist, Salesforce returns the origin in the Access-Control-Allow-Origin HTTP header along with any additional
CORS HTTP headers. If the origin isn’t included in the allowlist, Salesforce returns HTTP status
code 403.
- From Setup, use the Quick Find box to find and select
CORS.
- Select New.
- Enter a resource in Origin URL Pattern.
- Save your changes.
The origin URL pattern must include the HTTPS protocol (unless you’re using your localhost)
and a domain name. It can also include a port. The wildcard character (*) is supported and must
be in front of a second-level domain name. For example,
https://*.example.com adds all subdomains of
example.com to the allowlist.
The origin URL pattern can be an IP address. But an IP address and a domain that resolve to
the same address aren’t the same origin, and you must add them to the CORS allowlist as separate
entries.
Google Chrome™ and Mozilla® Firefox® browser extensions are allowed as resources in API version
53 (Winter ‘22) or later. Chrome extensions must use the prefix
chrome-extension:// and 32 characters without digits or capital letters,
for example chrome-extension://abdkkegmcbiomijcbdaodaflgehfffed. Firefox
extensions must use the prefix moz-extension:// and an 8-4-4-4-12 format of
small alphanumeric characters, for example
moz-extension://1234ab56-78c9-1df2-3efg-4567891hi1j2.
You can get a successful response when requesting a REST resource in a CORS preflight test,
but receive an unsuccessful response to the actual request. This discrepancy can occur when the
resource is deleted after the preflight test and before the request is made. It can also occur
if the resource doesn’t exist. A CORS preflight confirms if resources can be passed between
servers, but doesn’t check if a specific resource exists or not. CORS preflight requests are
typically issued automatically by a browser.
