Understanding SameSite cookie interaction with Cloudflare
Google Chrome’s SameSite cookie 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.
SameSite settings for Cloudflare cookies include:
|Cloudflare Cookie||SameSite Setting||HTTPS Only|
Known issues with SameSite and cf_clearance cookies
Cloudflare uses 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.
Use of the Secure flag requires sending the cookie via an HTTPS connection. The cf_clearance cookie defaults to SameSite=Lax if using HTTP on any part of your website and may cause website issues.
If using 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: