> ## Documentation Index > Fetch the complete documentation index at: https://docs-staging-quickstart-revamp.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Describes how to configure Cross-Origin Resource Sharing (CORS) for an Auth0-registered application using the Auth0 Dashboard. # Configure Cross-Origin Resource Sharing * For security purposes, your application's origin URL must be listed as an approved URL. If you have not already added it to the **Allowed Callback URLs** for your application, you will need to add it to the list of **Allowed Origins (CORS)**. * Ensure that **Allowed Web Origins** in your application's **Settings** view is set to the domain making the request. The URLs can contain wildcards for subdomains, but cannot contain relative paths after the domain URL. To learn more, read [Placeholders for Subdomains](/docs/get-started/applications/wildcards-for-subdomains). * If you don't enable [Custom Domains](/docs/customize/custom-domains), you will need to create a verification page that uses Auth0.js as the fallback for the cross-origin authentication. Cross-origin resource sharing (CORS) is a mechanism that allows an application to load data (resource) from a domain (origin) that is different from the one that it's hosted on. A CORS policy is an explicit exception to the same-origin policy common to web applications. For example, if you wanted your application (app.mydomain.com) to fetch a font from Google (fonts.google.com) in the background using Ajax, you would need to configure CORS. ## Configure cross-origin authentication 1. Go to [Dashboard > Applications > Applications](https://manage.auth0.com/#/applications) and click the name of the application to view. 2. Under **Cross-Origin Authentication**, toggle on **Allow Cross-Origin Authentication**. 3. Locate **Allowed Origins (CORS)**, and enter your application's origin URL. To learn more about Origins, read [Origin on Mozilla MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin). 4. Click **Save Changes**. If you do not need to use CORS for your application, ensure that **Allow Cross-Origin Authentication** is toggled off. ## Create cross-origin verification page There are some cases when third-party cookies will not be available. Certain browser versions do not support third-party cookies and, if they do, they may be disabled in a user's settings. For [browsers that are supported](#browser-testing-support), you can use the `crossOriginVerification` method from the [Auth0.js SDK](/docs/libraries/auth0js) in your application on a dedicated page to handle cases when third-party cookies are disabled. For browsers that are not supported, such as Chrome, Opera, and Safari, cross-origin authentication will not work when third-party cookies are disabled unless you enable [Custom Domains](/docs/customize/custom-domains). **Safari's** configuration is labeled as "Prevent cross-site tracking" and uses [Intelligent Tracking Prevention](https://webkit.org/blog/7675/intelligent-tracking-prevention/). Unfortunately, this also prevents third-party cookies from being useful in authentication scenarios. Here's an example of how it affects [token renewal](/docs/troubleshoot/authentication-issues/renew-tokens-when-using-safari). 1. Create a page in your application that instantiates `WebAuth` from [Auth0.js](/docs/libraries/auth0js). Call `crossOriginVerification` immediately. The name of the page is up to you. {/* codeblockOld.header.login.logInButton codeblockOld.header.login.configureSnippet */} ```text lines ``` When third party cookies are not available, Auth0.js renders an iframe to call a different cross-origin verification flow. 2. Go to [Dashboard > Applications > Applications](https://manage.auth0.com/#/applications), and select the application to view. 3. Under **Cross-Origin Authentication**, add the URL of the callback page you created to the **Cross-Origin Verification Fallback URL** field. For production environments, verify that the URL for the page does not point to `localhost`. The page must be in the same domain where the embedded login form is hosted and must have an `https` scheme. 4. Click **Save Changes**. For more details, view the [cross-origin authentication sample on GitHub](https://github.com/auth0/lock/blob/master/support/callback-cross-auth.html). ## Error codes and descriptions Error descriptions are intended to be human-readable. They are subject to change at any time and should not be parsed by any code. When Auth0.js v9 (and Lock) is used for embedded login, it calls the `/co/authenticate` endpoint, which has the following errors:

Status	Code	Description
`400`	`invalid\_request`	Invalid request body. All and only of client\_id, credential\_type, username, otp, realm are required.
`400`	`unsupported\_credential\_type`	Unknown credential type parameter.
`400`	`invalid\_request`	Unknown realm non-existent-connection.
`401`	`unauthorized\_client`	Cross origin login not allowed.
`401`	`password\_leaked`	This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application).
`403`	`access\_denied`	Wrong email or password.
`403`	`access\_denied`	Authentication error
`403`	`blocked\_user`	Blocked user
`429`	`too\_many\_attempts`	Your account has been blocked after multiple consecutive login attempts. We've sent you a notification via your preferred contact method with instructions on how to unblock it.
`429`	`too\_many\_attempts`	We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.

In addition, you can also get a generic `403` error without an `error` or `error_description` property. The response body would just include something similar to the following: `Origin https://test.app is not allowed.` ## Browser testing support The following browsers can use cross-origin authentication when third-party cookies are disabled: * Microsoft Internet Explorer Previously, the [`samesite` cookie attribute](/docs/manage-users/cookies/samesite-cookie-attribute-changes) options were `true`, `false`, `strict` or `lax`. If you didn't set the attribute manually, Auth0 would use the default value of `false`. Effective February 2020, Google Chrome v80 changed the way it handles cookies, and Auth0 implemented the following changes accordingly: * Cookies without the `samesite` attribute set will be set to `lax`. * Cookies with `sameSite=none` must be secured, otherwise they cannot be saved in the browser's cookie jar. The goal of these changes are to improve security and help mitigate cross-site resource forgery (CSRF) attacks. ## Learn more * [Embedded Login](/docs/authenticate/login/embedded-login) * [Cross-Origin Authentication](/docs/authenticate/login/cross-origin-authentication) * [Application Settings](/docs/get-started/applications/application-settings) * [SameSite Cookie Attribute Changes](/docs/manage-users/cookies/samesite-cookie-attribute-changes)