Understanding SameSite cookie interaction with Cloudflare
changes how Google Chrome handles the SameSite control. Google enforces SameSite 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 has 3 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 domain apex (e.g. *.foo.com). For example, if someone (blog.naughty.com) hotlinked an image (img.foo.com/bar.png), the client doesn’t send a cookie to img.foo.com since it is neither the first-party nor apex context.
- None: Cookies are sent with all requests.
|Cloudflare Cookie||SameSite Setting||HTTPS Only|
When configuring SameSite attributes on session affinity cookies, it is recommended that you set the values. The value
Auto is translated to
Lax if Always Use HTTPS is enabled, or
None if Always Use HTTPS is disabled. When using the value
None, the secure attribute cannot be set to
- Default value:
- Valid values:
Known issues with SameSite and cf_clearance cookies
SameSite=None in the
cf_clearance cookie so that visitor requests from different hostnames are not met with subsequent challenges or errors. When
SameSite=None is used, it must be set in conjunction with 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 to assist: