Troubleshooting and FAQ
Answers to common questions about Cloudflare Access.
How does Cloudflare Access evaluate tokens?
Cloudflare Access assigns JWTs (JSON web tokens) during authentication and looks for them in 1 of 2 places: a cookie in the browser or a custom authentication header.
The cookie name is
CF_Authorization. The header value is
Does Access support multi-factor authentication?
Access will enforce the multi-factor authentication (MFA) settings of the identity provider configured. Access does not have an independent or out-of-band MFA feature.
Access is subjected to the MFA policies set in your identity provider. For example, users attempting to log in to an Access protected app might login through Okta. Okta would enforce an MFA check before sending the valid authentication confirmation back to Cloudflare Access.
I get an error saying `No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Cloudflare Access requires that the
Does the application behind Access need to use HTTPS?
Yes. Cloudflare Access only secures applications that use HTTPS.
Can Access enforce rules on a specific, nonstandard, port?
No. Cloudflare Access cannot enforce a rule that would contain a port appended to the URL.
However, you can use Cloudflare Argo Tunnel to point traffic to nonstandard ports. For example, if Jira is available at port 8443 on your origin, you can proxy traffic to that port via with Argo Tunnel.
Rules and policies
What is the order of policy enforcement?
Access policies trigger in order based on their position in the policy table in the UI. The exception is Bypass policies, which Access evaluates first.
For Allow and Deny policies, Access enforces the decision starting at the top of your list and continues down the list. You can modify the order by dragging and dropping individual policies in the UI.
Can I use Access to secure applications with a second-level subdomain URL?
Yes. Ensure that your SSL certificates cover the first- and second-level subdomain. Most certificates only cover the first-level subdomain and not the second. This is true for most Cloudflare certificates. To cover a second-level subdomain with a CF certificate, select the Custom Host names option for Dedicated SSL.
Wildcard-based policies in Cloudflare Access only cover the level where they are applied. Add the wildcard policy to the left-most subdomain to be covered.
Can multiple paths be protected with a single policy?
By default, Cloudflare Access includes an implicit wildcard at the end of each path. For example, a rule protecting
jira.team.comwill automatically protect
jira.team.com/tick-1. However, wildcards cannot be included within a path.
Can I customize my domain by adding a logo from an HTTP URL?
No. The image is served from an HTTPS endpoint. For example,
http://www.example.com/upload/logo.pngdoes not work. However,
What browsers are supported?
These browsers are supported:
- Internet Explorer® 11
- Edge® (current release, last release)
- Firefox® (current release, last release)
- Chrome® (current release, last release)
- Safari® (current release, last release)
How are active seats measured?
Cloudflare Access counts any unique user who authenticated in a calendar month as an active user. This resets at the beginning of each calendar month.
curl to review the configuration
You can use the command-line tool
curl to review your configuration. To do so, you will need three prerequisites:
- An OPTIONS request
- An origin header
- The Access-Control-Request-Method
curl command below includes all three.
curl -I -XOPTIONS https://app2.site.com \ -H 'origin: https://app1.almightyzero.com' \ -H 'access-control-request-method: GET'
If configured, Cloudflare will return a response similar to the following example:
HTTP/2 200date: Wed, 22 Apr 2020 18:17:44 GMTset-cookie: __cfduid=d886c3e5dd7b8c4daba5f9f0cd173c3511587579464; expires=Fri, 22-May-20 18:17:44 GMT; path=/; domain=.almightyzero.com; HttpOnly; SameSite=Laxvary: Origin, Access-Control-Request-Method, Access-Control-Request-Headersaccess-control-allow-origin: https://app1.almightyzero.comaccess-control-allow-methods: GETaccess-control-allow-credentials: trueexpect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"server: cloudflarecf-ray: 588157e55e0882d7-ATLcf-request-id: 0244b54354000082d7b991f200000001
CORS requests that do not require OPTIONS (Simple Requests)
Cross-origin requests that do not require a specific OPTIONS preflight are common known as . The browser will still require the correct CORS headers, but will not send a preflight OPTIONS request to retrieve them. To make one of these requests, the
CF_authorization cookie must be included. CORS configurations made in the Cloudflare Access dashboard will not be applied; these CORS headers must come from the origin.
Requests that do not include the cookie will be redirected to the Cloudflare Access login page.
In general, we recommend the following steps when troubleshooting CORS issues:
- Capture a HAR file with the issue described.
- Ensure that the application has set
credentials: 'same-origin'in all fetch or XHR requests.
- If you are using the on script tags, these must be set to "use-credentials".
CORS on a different domain fails only on the first load
If you have two sites protected by Cloudflare Access,
app2.hostname.com, requests made between the two will be subject to CORS checks. Users who login to
app1.site.com will be issued cookies for
app1.site.com and your Cloudflare Access authentication domain.
When the user's browser requests
app2.hostname.com, the cookie will not be present for that domain so the request will be sent to the login page. However, the user will have a cookie for their Cloudflare Access session, which will redirect them successfully to
app2.hostname.com if they are permitted to reach it.
During this entire flow, the browser itself will check CORS headers. As part of that behavior, the browser will make the
Origin header null once a 302 has occurred. Cloudflare Access honors all redirects, however, the final redirect of a login will be made to the original domain. Since the
Origin header is still null, unless the configuration allows all origins, the request will now fail due to the browser's CORS issue. A refresh will resolve this for the user.
This can be addressed with the following settings:
- Use the
nullas an allowed origin.
Safari, in particular Safari 13.1, handles cookies in a unique format. In some cases, this can cause CORS to fail. This will be dependent on Apple releasing a patch for handling cookies. This is known to impact macOS 10.15.4 when running Safari 13.1 (15609.1.20.111.8).
CORS failing on the same domain
CORS checks do not occur on the same domain. If this error occurs, it is likely the user flow is making a sub-request without the cookie.