The user is on site-a.com and there is an iframe with site-b.com. site-b.com makes GET request back to site-a.com (inside iframe). Will Lax cookies for cross-site GET to site-a.com be send with the request?
To be more clear:
Before GET request: site-b.com iframed in site-a.com
After GET request: site-a.com iframed in site-a.com
From my observation in Chrome 91 canary this cookie is blocked, while it is not blocked in Chrome 88. I thought that only Lax+POST is problematic but it looks like also Lax+GET is now blocked in some cases. Is there any information/spec. about cross-site GET+Lax cookies?
First off, the request from site-b.com to site-a.com is a cross-site request. Doesn't matter if it's a GET or POST, the fact that it's between two different registrable domains (a.k.a. eTLD+1s) means it's cross-site.
The specification allows for Lax cookies to be sent with cross-site requests only if they are top-level requests AND have a safe method (GET, but not POST):
* If the cookie's same-site-flag is not "None", and the HTTP
request is cross-site (as defined in Section 5.2) then exclude
the cookie unless all of the following statements hold:
1. The same-site-flag is "Lax" or "Default".
2. The HTTP request's method is "safe".
3. The HTTP request's target browsing context is a top-level
browsing context.
A request inside an iframe is not a top-level request, hence Lax cookies aren't sent with a cross-site request on an iframe, regardless of what the request method is.
Chrome used to have a bug in this behavior, where the top-level requirement wasn't followed exactly. (It used to be that Chrome would send Lax cookies if the iframe and all of its ancestors matched the top level. This was buggy because the spec says it literally needs to be the top level.) What you're seeing is the correct behavior after the bug was fixed in Chrome 90.
Chrome 80 and up (released on 4/Feb/2020) enforces setting the SameSite attribute (which I downloaded one day early using Chrome Beta to test my site).
It gives my site the following error:
A cookie associated with a cross-site resource at URL was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
I've looked in Application>Storage>Cookies but I have only one cookie set which looks like this:
How do I know which Cookie was blocked and which request it was blocked on?
Does this issue causes a cookie to not be set OR does it cause a cookie not to be sent in an HTTP request?
Does it treat cookies set client side and cookies set server side (using the Set-Cookie response header) differently?
Thanks
See here for more info: https://www.chromium.org/updates/same-site/test-debug
How do I know which Cookie was blocked and which request it was blocked on?
You will need to look through the Network panel in DevTools, find the request, and look at the filtered out cookies.
Does this issue causes a cookie to not be set OR does it cause a cookie not to be sent in an HTTP request?
Both are possible.
Does it treat cookies set client side and cookies set server side (using the Set-Cookie response header) differently?
No.
I am sending a httponly/secure cookie to the client from my server running at default port. From the client, the request does not specify any port number for this and gets the cookie back in response.
When another call is made to the same server with different port, the cookies are not sent to the server. whereas if I make the call without any port number, the cookies are sent.
What am I missing here? Is there anything needs to be enabled in order for cookie to be sent cross domain. According to RFC 6265, cookies are not port specific, then is it specific browser behavior thats preventing this? I have tried Firefox and chrome and its not working on both.
Although this is an old question, I'm posting this for people who encounter the problem and find themselves here. This is likely caused by cross origin policy.
It can be circumvented by making sure your server sends "allow-credentials" CORS headers. And then you need to send your XHR with a "withCredentials" parameter.
I have a page on domain A which loads a webworker script from domain B. The webworker is fetching some PNGs from doman A's server.
In Firefox, the request to get the PNGs contains the cookie for my site (domain A).
In Chrome, it does not include the cookie for my site, and so fails because the request must be coming from a logged in user (which requires the session cookie to be sent in the request).
Which browser is behaving correctly, and can I do anything to make Chrome send the cookie for the current domain from within a webworker?
UPDATE:
I pulled all the files from domain B and hosted them on my server at domain A, so the webworker file is now on the same domain as the site itself, but Chrome still does not send the session cookie with the requests from the web worker.
With regards to the first problem, it looks like the Firefox is incorrect, you shouldn't be able to instantiate a Worker on another domain to quote the spec:
"If the scheme component of worker URL is not "data", and the origin
of worker URL is not the same as the origin specified by the incumbent
settings object, then throw a SecurityError exception and abort these
steps."
With regards to Chrome the Workers run in a separate they work for me and without seeing more code it's hard to answer. But if you visit this demo and break before the postMessage to the worker set document.cookie='test=1' you will see that when the request goes out from the worker it is set.
I don't understand: how are webserver and trackers like Google Analytics able to track referrals?
Is it part of HTTP?
Is it some (un)specified behavior of the browsers?
Apparently every time you click on a link on a web page, the original web page is passed along the request.
What is the exact mechanism behind that? Is it specified by some spec?
I've read a few docs and I've played with my own Tomcat server and my own Google Analytics account, but I don't understand how the "magic" happens.
Bonus (totally related) question: if, on my own website (served by Tomcat), I put a link to another site, does the other site see my website as the "referrer" without me doing anything special in Tomcat?
Referer (misspelled in the spec) is an HTTP header. It's a standard header that all major HTTP clients support (though some proxy servers and firewalls can be configured to strip it or mangle it). When you click on a link, your browser sends an HTTP request that contains the page being requested and the page on which the link was found, among other things.
Since this is a client/request header, the server is irrelevant, and yes, clicking a link on a page hosted on your own server would result in that page's URL being sent to the other site's server, though your server may not necessarily be accessible from that other site, depending on your network configuration.
One detail to add to what's already been said about how browsers send it: HTTPS changes the behavior a bit. I am not aware if it's in any spec, but if you jump from HTTPS to HTTP, and if you stay on the same domain or go to different domains, then sometimes the referrer is not sent. I don't know the exact rules, but I've observed this in the wild. If there's some spec or description about this, it would be great.
EDIT: ok, the RFC says plainly:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
So, if you go from HTTPS page to a HTTP link, referrer info is not sent.
From: http://en.wikipedia.org/wiki/HTTP_referrer
The referrer field is an optional part
of the HTTP request sent by the
browser program to the web server.
From RFC 2616:
The Referer[sic] request-header field
allows the client to specify, for
the server's benefit, the address
(URI) of the resource from which
the Request-URI was obtained (the
"referrer", although the header
field is misspelled.)
If you request a web page using a browser, your browser will sent the HTTP Referer header along with the request.
Your browser passes referrer with each page request.
It seems unusual that JavaScript has access to this as well, but it does.
Yes, the browser sends the previous page in the HTTP headers. This is defined in the HTTP/1.1 spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36
The answer to your question is yes, as the browser sends the referer.
"The referrer field is an optional part of the HTTP request sent by the browser program to the web server."
http://en.wikipedia.org/wiki/HTTP_referrer
When you click on a link the browser adds a Referer header to the request. It is part of HTTP. You can read more about it here.