SameSite cookie interaction with Cloudflare
Google Chrome enforces SameSite cookie behavior ↗ to protect against marketing cookies that track users and Cross-site Request Forgery (CSRF) that allows attackers to steal or manipulate your cookies.
The SameSite cookie attribute has three different modes:
- Strict: Cookies are created by the first party (the visited domain). For example, a first-party cookie is set by Cloudflare when visiting
cloudflare.com. - Lax: Cookies are only sent to the apex domain (such as
example.com). For example, if someone (blog.example.net) hotlinked an image (img.example.com/bar.png), the client does not send a cookie toimg.example.comsince it is neither the first-party nor apex context. - None: Cookies are sent with all requests.
SameSite settings for Cloudflare cookies include:
| Cloudflare cookie | SameSite setting | HTTPS Only | Partitioned (CHIPS) |
|---|---|---|---|
__cf_bm | SameSite=None; Secure | Yes | No |
cf_clearance | SameSite=None; Secure | Yes | Yes |
__cflb | SameSite=Lax | No | No |
Currently, to configure the SameSite attribute on session affinity cookies you must use the Cloudflare API (for example, the Create Load Balancer operation).
To configure the value of the SameSite cookie attribute, include the samesite and secure JSON attributes in your HTTP request, inside the session_affinity_attributes object.
The available values for these two attributes are the following:
samesite attribute:
- Valid values:
Auto(default),Lax,None,Strict.
secure attribute:
- Valid values:
Auto(default),Always,Never.
The Auto value for the samesite attribute will have the following behavior:
- If Always Use HTTPS is enabled, session affinity cookies will use the
LaxSameSite mode. - If Always Use HTTPS is disabled, session affinity cookies will use the
NoneSameSite mode.
The Auto value for the secure attribute will have the following behavior:
- If Always Use HTTPS is enabled, session affinity cookies will include
Securein the SameSite attribute. - If Always Use HTTPS is disabled, session affinity cookies will not include
Securein the SameSite attribute.
If you set samesite to None in your API request, you cannot set secure to Never.
If you require a specific SameSite configuration in your session affinity cookies, Cloudflare recommends that you provide values for samesite and secure different from Auto, instead of relying on the default behavior. This way, the value of the SameSite cookie attribute will not change due to configuration changes (namely Always Use HTTPS).
When a visitor solves a challenge presented due to a custom rule or an IP access rule, a cf_clearance cookie is set in the visitor's browser. The cf_clearance cookie has a default lifetime of 30 minutes, which you can configure via Challenge Passage.
Cloudflare uses SameSite=None in the cf_clearance cookie so that visitor requests from different hostnames are not met with later challenges or errors. When SameSite=None is used, it must be set in conjunction with the Secure flag.
Using the Secure flag requires sending the cookie via an HTTPS connection. If you use HTTP on any part of your website, the cf_clearance cookie defaults to SameSite=Lax, which may cause your website not to function properly.
To resolve the issue, move your website traffic to HTTPS. Cloudflare offers two features for this purpose:
Cloudflare sets the Partitioned attribute on the cf_clearance cookie (and on the internal cf_chl_* cookies used by the Challenge Platform) to comply with Cookies Having Independent Partitioned State (CHIPS) ↗ ↗.
With CHIPS, a cookie set in a third-party context (for example, inside an iframe or from a cross-site subresource) is stored in a partition keyed to the top-level site, rather than being shared across all sites that embed the third party. On Chromium-based browsers that block third-party cookies, this preserves challenge state for cross-site embeds that would otherwise be broken. On browsers that do not implement CHIPS, the Partitioned attribute is ignored and behavior is unchanged.
The Partitioned attribute is not applied to __cf_bm.
Because cf_clearance is partitioned, a clearance obtained in one top-level context is not reused in a different top-level context. A visitor who passes a challenge while browsing a site directly will not automatically carry that clearance into another site that embeds it, and vice versa. This is the intended behavior under CHIPS.
The Partitioned attribute only takes effect on cookies that are also set with SameSite=None; Secure. If your site does not serve all traffic over HTTPS, the cf_clearance cookie falls back to SameSite=Lax (refer to Known issues with SameSite and cf_clearance cookies), and the Partitioned attribute has no effect.