Develop Reference

I created an api in express, and a page in react to consume this api, but the page is not sending the cookie in headers [duplicate]

I am trying to send Cookies to a PHP Script within a javascript fetch CORS request. The Request starts on https://sub1.example.com and contains the following options:
let response = await fetch('https://sub2.example.com/target.php', {
method: "POST",
headers: headers,
body: formData,
mode: 'cors',
credentials: 'include',
cache: 'no-store'
});
The corresponding PHP Script sets the following Headers:
header('Access-Control-Allow-Origin: https://www.example.com');
header('Access-Control-Allow-Methods: POST, OPTIONS');
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Request-With, Set-Cookie, Cookie, Bearer');
But the Cookie Header is not send with the request. I also tried:
let headers = new Headers();
headers.set('Cookie', document.cookie);
That also had no effect. What exactly am I doing wrong here?
I checked the Network Tab in the Development Tools. Also $_COOKIE in the PHP Script is empty. There is absolutely no error. I can also see that the Cookie Header is sent in any not CORS fetch request.
EDIT: Here are the Settings of one of the Cookies:
Name: PHPSESSID
Path: /
Secure: true
SameSite: none
I can't share the Domain because it's not public. But the Cookie Domain has the same Value as the Origin in the Request Header (Minus the https://).
EDIT 2: Changed the fetch URL to make clearer what's happening.

Problem
Be aware that, depending on
the value of the cookie's Path attribute,
the effective value of the cookie's Domain attribute,
the value of the cookie's Secure attribute,
the effective value of the cookie's SameSite attribute,
the request's issuing and destination origins,
a cookie may or may not be attached to the request. Of particular relevance to your case is the Domain attribute; check out MDN's page on the topic:
The Domain attribute specifies which hosts can receive a cookie. If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.
You're setting the cookie as follows on origin https://sub1.example.com:
Set-Cookie: PHPSESSID=whatever; Path=/; SameSite=None; Secure
Therefore, that cookie will get attached to (credentialed) requests whose destination origin is https://sub1.example.com, and no other.
Solution
If you want your cookie to be sent to all secure origins whose domain is an example.com subdomain, you need to explicitly set its Domain to example.com.
About sending cookies with fetch
The Fetch standard specifies a list of forbidden header names; Cookie is one of them. You cannot set a header named Cookie on a request sent with fetch; the standard simply forbids it. If you want to attach existing cookies to a cross-origin request, use the 'include' value for the credentials parameter passed in fetch options.

Cookies normally are not supposed to be attached to preflight requests in CORS mode. You might want to check this out.
Note: Browsers should not send credentials in preflight requests irrespective of this setting. For more information see: CORS > Requests with credentials.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

These are the conditions that need to be met in order for the browser to save and then use cookies initiated using fetch:
Client initializes asynchronously a fetch request with credentials: 'include'. See [here][1] for more details.
To do CORS, server response header must contain Access-Control-Allow-Origin explicitly set to a domain, could be different from the server domain. For example, in a Single-Page-App architecture, your frontend site is temporarily hosted at localhost:3000 and your backend server hosted at localhost:8000, then the header should be Access-Control-Allow-Origin: http://localhost:3000. See [here][2] and [here][3].
To allow client to process cookies, which is obviously a sensitive resource, server response header must further contain Access-Control-Allow-Credentials: true. See [here][4]. Note that this enforces a non-wildcard setting for Access-Control-Allow-Origin. See [here][6] - that's why in point 2 above, it has to be explicitly set to something like http://localhost:3000 rather than *
When server sets the cookie, it has to include SameSite=None; Secure; HttpOnly. So overall something like Set-Cookie: session_id=12345; SameSite=None; Secure; HttpOnly. SameSite seems to be a relatively [new requirement][5] in latest browsers, and must be used with Secure together when SameSite is set to None.
With regard to HttpOnly, I haven't found relevant materials, but in my experiment, omitting it caused the browser to ignore the Set-Cookie header.
Further requests to the backend server also must have credentials: 'include' set.
Source: https://stackoverflow.com/a/67001424/368691

HttpOnly Cookie and fetch

Will a cookie with the HttpOnly and Secure attributes be sent using Fetch API in case {credentials: "include"} is present in options?
fetch("https://some.url", {
mode: "same-origin",
credentials: "include",
redirect: "manual"
})

There are several conditions that have to be met, but yes they are.
Client initializes asynchronously a fetch request with credentials: 'include'. See [here][1] for more details.
To do CORS, server response header must contain Access-Control-Allow-Origin explicitly set to a domain, could be different from the server domain. For example, in a Single-Page-App architecture, your frontend site is temporarily hosted at localhost:3000 and your backend server hosted at localhost:8000, then the header should be Access-Control-Allow-Origin: http://localhost:3000. See [here][2] and [here][3].
To allow client to process cookies, which is obviously a sensitive resource, server response header must further contain Access-Control-Allow-Credentials: true. See [here][4]. Note that this enforces a non-wildcard setting for Access-Control-Allow-Origin. See [here][6] - that's why in point 2 above, it has to be explicitly set to something like http://localhost:3000 rather than *
When server sets the cookie, it has to include SameSite=None; Secure; HttpOnly. So overall something like Set-Cookie: session_id=12345; SameSite=None; Secure; HttpOnly. SameSite seems to be a relatively [new requirement][5] in latest browsers, and must be used with Secure together when SameSite is set to None.
With regard to HttpOnly, I haven't found relevant materials, but in my experiment, omitting it caused the browser to ignore the Set-Cookie header.
Further requests to the backend server also must have credentials: 'include' set.
Source: https://stackoverflow.com/a/67001424/368691

Javascript fetch is not sending Cookie Header (CORS)

I am trying to send Cookies to a PHP Script within a javascript fetch CORS request. The Request starts on https://sub1.example.com and contains the following options:
let response = await fetch('https://sub2.example.com/target.php', {
method: "POST",
headers: headers,
body: formData,
mode: 'cors',
credentials: 'include',
cache: 'no-store'
});
The corresponding PHP Script sets the following Headers:
header('Access-Control-Allow-Origin: https://www.example.com');
header('Access-Control-Allow-Methods: POST, OPTIONS');
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Request-With, Set-Cookie, Cookie, Bearer');
But the Cookie Header is not send with the request. I also tried:
let headers = new Headers();
headers.set('Cookie', document.cookie);
That also had no effect. What exactly am I doing wrong here?
I checked the Network Tab in the Development Tools. Also $_COOKIE in the PHP Script is empty. There is absolutely no error. I can also see that the Cookie Header is sent in any not CORS fetch request.
EDIT: Here are the Settings of one of the Cookies:
Name: PHPSESSID
Path: /
Secure: true
SameSite: none
I can't share the Domain because it's not public. But the Cookie Domain has the same Value as the Origin in the Request Header (Minus the https://).
EDIT 2: Changed the fetch URL to make clearer what's happening.

Problem
Be aware that, depending on
the value of the cookie's Path attribute,
the effective value of the cookie's Domain attribute,
the value of the cookie's Secure attribute,
the effective value of the cookie's SameSite attribute,
the request's issuing and destination origins,
a cookie may or may not be attached to the request. Of particular relevance to your case is the Domain attribute; check out MDN's page on the topic:
The Domain attribute specifies which hosts can receive a cookie. If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.
You're setting the cookie as follows on origin https://sub1.example.com:
Set-Cookie: PHPSESSID=whatever; Path=/; SameSite=None; Secure
Therefore, that cookie will get attached to (credentialed) requests whose destination origin is https://sub1.example.com, and no other.
Solution
If you want your cookie to be sent to all secure origins whose domain is an example.com subdomain, you need to explicitly set its Domain to example.com.
About sending cookies with fetch
The Fetch standard specifies a list of forbidden header names; Cookie is one of them. You cannot set a header named Cookie on a request sent with fetch; the standard simply forbids it. If you want to attach existing cookies to a cross-origin request, use the 'include' value for the credentials parameter passed in fetch options.

Cookies normally are not supposed to be attached to preflight requests in CORS mode. You might want to check this out.
Note: Browsers should not send credentials in preflight requests irrespective of this setting. For more information see: CORS > Requests with credentials.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

These are the conditions that need to be met in order for the browser to save and then use cookies initiated using fetch:
Client initializes asynchronously a fetch request with credentials: 'include'. See [here][1] for more details.
To do CORS, server response header must contain Access-Control-Allow-Origin explicitly set to a domain, could be different from the server domain. For example, in a Single-Page-App architecture, your frontend site is temporarily hosted at localhost:3000 and your backend server hosted at localhost:8000, then the header should be Access-Control-Allow-Origin: http://localhost:3000. See [here][2] and [here][3].
To allow client to process cookies, which is obviously a sensitive resource, server response header must further contain Access-Control-Allow-Credentials: true. See [here][4]. Note that this enforces a non-wildcard setting for Access-Control-Allow-Origin. See [here][6] - that's why in point 2 above, it has to be explicitly set to something like http://localhost:3000 rather than *
When server sets the cookie, it has to include SameSite=None; Secure; HttpOnly. So overall something like Set-Cookie: session_id=12345; SameSite=None; Secure; HttpOnly. SameSite seems to be a relatively [new requirement][5] in latest browsers, and must be used with Secure together when SameSite is set to None.
With regard to HttpOnly, I haven't found relevant materials, but in my experiment, omitting it caused the browser to ignore the Set-Cookie header.
Further requests to the backend server also must have credentials: 'include' set.
Source: https://stackoverflow.com/a/67001424/368691

How do I use window.fetch() with httpOnly cookies or basic auth

I'm playing around with window.fetch() in Firefox and Chrome. For some reasons, fetch() doesn't send any cookies. Now that wouldn't be a problem, as I can send them using
fetch('/something', { headers: { Cookie: document.cookie } })
But this won't work for httpOnly cookies.

Okay, I found out after reading on the Mozilla Developer Network a bit more and trying out the credentials option.
Looks like the credentials option is what I should have looked for.
fetch('/something', { credentials: 'same-origin' }) // or 'include'
Will send the cookies.

There are three points here:
If you're making a cross-origin request, set the Access-Control-Allow-Credentials: true. So that the server accepts your cookies.
Set the credentials options either to include for cross-origin requests or same-origin for same-origin requests
Set the credentials option of fetch on both requests that you retrieve and send the cookie

Can jQuery.getJSON put a domain's cookies in the header of the request it makes?

(Note: See also the related question Can browsers react to Set-Cookie specified in headers in an XSS jquery.getJSON() request?)
I can't seem to set a cookie (whose name is mwLastWriteTime) in the request header of a JSON operation. The request itself is a simple one from the Freebase MQL tutorials, and it is working fine otherwise:
// Invoke mqlread and call the function below when it is done.
// Adding callback=? to the URL makes jQuery do JSONP instead of XHR.
jQuery.getJSON("http://api.sandbox-freebase.com/api/service/mqlread?callback=?",
{query: JSON.stringify(envelope)}, // URL parameters
displayResults); // Callback function
I'd hoped that I could set this cookie with something along the lines of:
$.cookie('mwLastWriteTime', value, {domain: ".sandbox-freebase.com"});
Unfortunately, looking in FireBug at the outgoing request header I see only:
Host api.sandbox-freebase.com
User-Agent [...]
Accept */*
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer [...]
But if I don't specify the domain (or if I explicitly specify the domain of the requesting site) I can get mwLastWriteTime to show up in the headers for local requests. Since the .sandbox-freebase.com domain owns these cookies, shouldn't they be traveling along with the GET? Or does one need a workaround of some sort?
My code is all JavaScript, and I would like to set this cookie and then call the getJSON immediately afterward.

You cannot set a cross-domain cookie, because that would open the browser (and therefore the user) to XSS attacks.
To quote from the QuirksMode.org article that I reference above:
Please note that the purpose of the
domain is to allow cookies to cross
sub-domains. My cookie will not be
read by search.quirksmode.org because
its domain is www.quirksmode.org .
When I set the domain to
quirksmode.org, the search sub-domain
may also read the cookie. I cannot set
the cookie domain to a domain I'm not
in, I cannot make the domain
www.microsoft.com . Only
quirksmode.org is allowed, in this
case.
If you want to make cross-site request with cookie values you will need to set up a special proxy on a server you control that will let you pass in values to be sent as cookie values (probably via POST parameters). You'll also want to make sure that you properly secure it, lest your proxy become the means by which someone else's private information is "liberated".

Are you running all of your tests through localhost? Are you using IE? If so it will be enforcing its own special brand of security requirements and likely dumping your cookies. Open fiddler and use http://ipv4.fiddler to bypass that.
If that type of trickery is not going on (as it appears you are using FireFox) , it may also be the case that you do need to explicitely set the cookie's domain to be the same as the domain of your JSON request. A browser won't send cookies set for domain A to a request to domain B. I am not 100% sure this is the case though.