Does CORS Access-Control-Allow-Credentials apply to non-origin/third-party cookies or as well?

Question

I understand if you are cross-communicating with origin A, then if origin A has no Access-Control-Allow-Credentials in the response, you will never be able to reuse Cookies obtained from origin A response.

But what if you got a cookie in the browser with domain=A but not obtained directly from the servie, would it still be allowed to be send in a request to A without A having Access-Control-Allow-Credentials enabled?

EDIT:

I really worded it bad.

Let's imagine I have a domainA which is served by multiple microservices under-the-hood

when you execute https://domainA/ you log in and get a JWT cookie with domain=domainA

then you try to access https://domainA/mymicroserviceA1 and nginx redirects this to mymicroserviceA1, which is a fully operating server.

My question is, does the tuning of Access-Control-Allow-Credential in mymicroserviceA1 affect only the possibility of reusing cookies originated inm mymicroserviceA1 or does it forbid also to reuse the original cookie you got already in the browser after login in https://domainA?

In other words, if I request GET https://domainA/mymicroserviceA1 will I send the cookie and be authenticated (assuming mymicroserviceA1 has CORS is allow=* and ACAC=omit, or even pure SOP)?

Answer 1

But what if you got a cookie in the browser with domain=A but not obtained directly from it

You can't do that. I mean, technically you could make a server send it, but it's a severe violation of the spec and the client would ignore it (and log an error). The domain flag on a cookie is only useful for specifying how the cookies behaves with regard to subdomains; it neither allows setting a cookie for the current site from a cross-site request, nor setting a cross-site cookie on a response from the current (or a different other) site.

---

Additionally, you seem... maybe a little confused about CORS, and the ACAC header. ACAC does not, generally speaking, control whether cookies get set or not. Nor does it have any impact whatsoever in non-CORS responses, or in responses to CORS requests made without credentials ("credentials" typically mean cookies, but could also be HTTP Basic or Digest auth, or TLS client certificates, or potentially any other credential that the browser normally sends automatically). ACAC does only two things:

1. For a "simple" request (one that you could make using an HTML form), ACAC: true in the response will - if the origin is an exact match - allow the requesting script to see the response even if credentials were included in the request. As mentioned above, if credentials weren't included, it doesn't even matter whether it's present or not. Also, the request might still have an effect on the server; the browser just won't let the client-side script see the response.
2. For a "non-simple" request (one which uses a any content type an HTML form doesn't support, manually sets any other header, uses a verb other than HEAD/GET/POST, or requests to see response headers), the browser will send a "pre-flight" OPTIONS request before sending the actual request. ACAC in response to the pre-flight may control whether the browser allows the requesting script to send the actual request at all; if the script specified to include credentials in the request but the server doesn't specify ACAC: true in the pre-flight response, the actual request won't be sent at all (even if everything else is allowed).

For same-origin requests, cross-origin non-CORS requests (e.g. using an HTML form submission), or CORS requests where credentials aren't included (as the browser thinks of them; if the client script sets a Bearer token or similar, that isn't the kind of "credentials" that ACAC cares about though it does cause the request to be pre-flighted because it's setting a header), then ACAC being present or not has no impact. Finally, ACAC: true can never be legally combined with Access-Control-Allow-Origin: *; if the server sends that, the browser must ignore the ACAC header. The value of the ACAO header must exactly match the origin of the request before ACAC even is considered.

---

Edit to respond to your updated question:

Yes, so long as your redirection to "mymicroserviceA1" only happens within the server (without redirecting the client), cookies for "domainA" will be sent with such requests. After all, the browser doesn't can't tell the difference between a path that gets directed to a different microservice, and a path that is retrieving the same static resource on a monolithic server, or anything else like that. The browser has no way of knowing what any server component does with a request, and does not care what your internal server architecture looks like. In this case, ACAC (and all other CORS headers) are completely irrelevant, because this is a same-origin request, not a cross-origin one.

However, if you're having nginx redirect the browser (by means of a 3xx response, or possibly via script or meta tag) to a new domain - http[s]://mymicroserviceA1 or similar - then the browser will not send the cookies for "domainA" with the subsequent (redirected) request to "mymicroserviceA1". (However, the first request - the one to "domainA" that gets the 3xx response - could of course have cookies for "domainA".) Any cookies already set for "mymicroserviceA1" might get sent, but the browser would treat the two domains as completely different sites. In this case, whether cookies are sent would depend on the conditions below, but note that for navigation requests, resource requests, or CORS requests that specify to include credentials but don't require a pre-flight, the cookies will be sent even if your response contains ACAO:* and/or no ACAC. (Don't ever set ACAC to any value other than true, case sensitive, though other values should be treated as if the header wasn't there at all.)

There are a few things that control whether cookies are sent with a request. They are:

1. The domain to which the request is sent, as seen by the browser (redirects that happen within the server have no effect on what the browser considers the domain to be, though an HTTP 3xx response that redirects the browser to a new domain will change which cookies may be sent). Cookies are always associated with a domain (and potentially its subdomains), whether explicitly specified or not. Cookies are only ever sent if their associated domain matches (or, potentially, is a super-domain of) the domain of the request target.
2. The cookie's max-age or expiry period, relative to the current time (as the browser believes it to be). Cookies that the browser believes to be expired are never sent (and are usually deleted rapidly, such that setting back the system clock will not result in the expired cookies re-entering use unless the browser had failed to purge them in time).
3. The presence of the secure flag on the cookie will prevent the browser from sending them (or exposing them to scripts) on non-secure (typically meaning "http" rather than "https" or "ws" rather than "wss") requests.
4. The value (or absence and thus default value of "/") of the path flag on the cookie can control which requests include that cookie, so you could in theory make cookies which are sent for "https://domainA/mymicroserviceA1" but not for "https://domainA/". However, this is not security-relevant because those URLs have the same origin and thus an attacker could easily use XHR/Fetch, or invisible iframes, to bypass the path check.
5. The presence of the samesite flag, and its value, can restrict when cookies are sent on cross-domain requests (ones where the request originates on one domain but is destined for a different one). Samesite does not block all cross-domain requests (in particular, subdomains are generally considered the same "site") and definitely not all cross-origin requests (origin considers fields beyond domain, specifically scheme/protocol and port), but can prevent cross-domain transmission of cookies (which had previously been set for the target domain) if the cookies were set using the strict or lax values for samesite. Note that most modern browser versions default to lax if samesite is not otherwise specified.
6. Whether the request specifies that cookies are to be used. Navigation requests (both top-level and embedded or child windows) and resource requests (images, scripts, stylesheets, etc.) always send cookies (if any are allowed by all the checks above). Script-initiated requests (XMLHttpRequest or fetch API requests) may or may not include cookies, depending on whether the initiating script specified that "credentials" are to be sent. CORS pre-flight requests never send cookies. If credentials were sent (or are to be sent, in the case of a pre-flighted request) and the server either returns ACAO:* or fails to return ACAC:true, the browser will not let the client script see the response (and, for pre-flighted requests where the pre-flight responses doesn't pass that check, won't send the actual request at all).