This question already has an answer here:
A cookie associated with a cross-site resource was set without the `SameSite` attribute
(1 answer)
Closed 3 years ago.
I am getting this warning on my website with aframe
A cookie associated with a cross-site resource at http://aframe.io/ was set without the `SameSite` attribute. A future release of Chrome will only deliver 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.
Ok got my answer from here its the issue with aframe.io
A cookie associated with a cross-site resource was set without the `SameSite` attribute
as #rowan_m stated
The warning messages specifically call out the domain that's responsible for the cookie. In this case, it's aframe.io. Which means 'aframe.io' needs to update the cookie there.
https://web.dev/samesite-cookies-explained
https://web.dev/samesite-cookie-recipes.
Related
Not all the cookies shown by Chrome Dev Tools as part of the Request Header are found in the HttpServletRequest object.
Here is a screenprint from Chrome Dev Tools, showing the request headers for the GET HTTP request.
You can see that the "cookie" includes the "_fbp" cookie:
cookie request header
From the Chrome Dev Tools application tab, you can see that the "_fbp" cookie is from my same Domain and has not expired and is for Path / so it should be included (which it was):
cookie details
We're running a Java Spring MVC backend and when the request comes to the controller endpoint, we have the "HttpServletRequest request" parameter.
Examining that "request" object, I find that it has some of the cookies which were observed as part of the request, but not all of them... and specifically not the "_fbp" cookie I'm looking for.
Tried examining the cookies in all the following manners:
Object rhc = request.getHeader("Cookie");
Cookie wuc = org.springframework.web.util.WebUtils.getCookie(request, "_fbp");
parameter #CookieValue(name="_fbp", required=false) String fbpCookie
but no matter how I inspect that request, the "_fbp" cookie is not there. I noticed that most of the other cookies that are not found all have names beginning with underscores so I suspected maybe that is a naming convention that is ignored by Spring MVC but couldn't find any such rule.
Can anyone help explain the missing cookies? How can I get that "_fbp" cookie value for server-side processing? Appreciate any help.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I am struggling with Cache Control in my application.
Apparently my browser was requesting the HTML files with Max-Age=0. My web-server doesn't have a directive, but the CDN proxy was passing a cache directive with 24 hours time to live.
The question is, what happens if a browser pass No-Cache in the request, for example, but the server specifies a Cache time? What has the highest precedence?
Can I ignore cache completely from client, or am I always subject to what the server responds?
Thanks!
You are confusing the meaning of header in a request and in a response.
In a request header, MaxAge=0 means "I want the freshest version of this content from the origin server". A client should be able to specify a non-zero value and any proxy cache with a version older than that, even if it is still considered valid, should make a new request upstream, although the HTTP/1.1 spec is a little vague on this one.
In a response header, Max-Age=N means "here is the content and you can re-use for up to N seconds (less any specified value for the current Age) without asking for it again".
There is no conflict. A client is quite entitled to ask again before the cache time has expired.
There is a complication here if your origin server is not specifying a Max-Age (and not specifying an Expires header). It shouldn't do that (unless it has been explicitly told to do so). That suggests that the proxy is not behaving nicely and you should be talking to the proxy service provider.
Given that the proxy is not behaving nicely it may be serving up stale content even if the client is asking for a fresh copy.
However it's not all their fault. If you do not want the content to be cachable then you should be explicitly stating that in your response headers with Cache-control: no-cache. In the absence of explicitly caching directive a client and an intermediate cache may reuse content.
I am facing an issue in online payment portal ,when redirecting from merchant portal the session gets timedout in ios 12 browsers, i suspect this due to Samesite attribute not applying properly, currently it has been applied in revreseproxy level,are there any solutions for that ?
I've provided some detail on this here: https://web.dev/samesite-cookie-recipes/#handling-incompatible-clients
The summary is that you can either:
Set the same data in two separate cookies:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
On the receiving end, you can then check which cookie has been received. If the
legacy cookie is present, then you know you are dealing with an older browser
and can adjust accordingly.
Detect the browser based on the User-Agent value. There's a regular expression you can use here: https://www.chromium.org/updates/same-site/incompatible-clients however any form of User-Agent detection will be fragile, so exercise caution.
I try to implement a one time none for HTTP digest authentication process. First of all I'm aware of the fact that the authentication is not perfectly secure. Please do not tell me to use something else. The authentication process is working as expected. When the user authenticate successfully I append a http Authentication-Info field with the next nonce. The browser in this case Firefox is not using this nonce for further requests.
Authentication-Info: nextnonce="06e8043d3fb8c26156829c4b55afd13040"
Why is the browser not using my new nonce for future requests? It still uses the old now invalid one!
RFC7616 describes the header field.
https://www.rfc-editor.org/rfc/rfc7616#section-3.5
The value of the nextnonce parameter is the nonce the server
wishes the client to use for a future authentication response.
The server MAY send the Authentication-Info header field with a
nextnonce field as a means of implementing one-time nonces or
otherwise changing nonces. If the nextnonce field is present, ...
RFC2617 describes the syntax in section 3.2.3
https://www.ietf.org/rfc/rfc2617.txt
[Edit]
Is it possible that firefox is not supporting this feature. If I search here
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate
for the header field I can't find a result.
But it is listed as standard header flag here:
https://www.iana.org/assignments/message-headers/message-headers.xhtml
nextnonce is not supported in Firefox, not even Authentication-Info header.
The bug "next nonce digest auth test fails" was opened 18 years ago and it's still not fixed yet.
I downloaded the source code of the latest Firefox version 65.0.1 and searched the project. "Authentication-Info" only appears in netwerk/protocol/http/nsHttpDigestAuth.cpp as a comment, nowhere else.
MDN says, when the credentials like cookies, authorisation header or TLS client certificates has to be exchanged between sites Access-Control-Allow-Crendentials has to be set to true.
Consider two sites A - https://example1.xyz.com and another one is B- https://example2.xyz.com. Now I have to make a http Get request from A to B. When I request B from A I am getting,
"No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://example1.xyz.com' is therefore not allowed
access."
So, I'm adding the following response headers in B
response.setHeader("Access-Control-Allow-Origin", request.getHeader("origin"));
This resolves the same origin error and I'm able to request to B. When and why should I set
response.setHeader("Access-Control-Allow-Credentials", "true");
When I googled to resolve this same-origin error, most of them recommended using both headers. I'm not clear about using the second one Access-Control-Allow-Credentials.
When should I use both?
Why should I set Access-Control-Allow-Origin to origin obtained from request header rather than wildcard *?
Please quote me an example to understand it better.
Allow-Credentials would be needed if you want the request to also be able to send cookies. If you needed to authorize the incoming request, based off a session ID cookie would be a common reason.
Setting a wildcard allows any site to make requests to your endpoint. Setting allow to origin is common if the request matches a whitelist you've defined. Some browsers will cache the allow response, and if you requested the same content from another domain as well, this could cause the request to be denied.
Setting Access-Control-Allow-Credentials: true actually has two effects:
Causes the browser to actually allow your frontend JavaScript code to access the response if credentials are included
Causes any Set-Cookie response header to actually have the effect of setting a cookie (the Set-Cookie response header is otherwise ignored)
Those effects combine with the effect that setting XMLHttpRequest.withCredentials or credentials: 'include' (Fetch API) have of causing credentials (HTTP cookies, TLS client certificates, and authentication entries) to actually be included as part of the request.
https://fetch.spec.whatwg.org/#example-cors-with-credentials has a good example.
Why should I set Access-Control-Allow-Origin to origin obtained from request header rather than wildcard *?
You shouldn’t unless you’re very certain what you’re doing.
It’s actually safe to do if:
The resource for which you’re setting the response headers that way is a public site or API endpoint intended to be accessible by everyone, and
You’re just not setting cookies that could enable an attacker to get access to sensitive information or confidential data.
For example, if your server code is just setting cookies just for the purpose of saving application state or session state as a convenience to your users, then there’s no risk in taking the value of the Origin request header and reflecting/echoing it back in the Access-Control-Allow-Origin value while also sending the Access-Control-Allow-Credentials: true response header.
On the other hand, if the cookies you’re setting expose sensitive information or confidential data, then unless you’re really certain you have things otherwise locked down (somehow…) you really want to avoid reflecting the Origin back in the Access-Control-Allow-Origin value (without checking it on the server side) while also sending Access-Control-Allow-Credentials: true.
If you do that, you’re potentially exposing sensitive information or confidential data in way that could allow malicious attackers to get to it. For an explanation of the risks, read the following:
https://web-in-security.blogspot.jp/2017/07/cors-misconfigurations-on-large-scale.html
http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
And if the resource you’re sending the CORS headers for is not a public site or API endpoint intended to be accessible by everyone but is instead inside an intranet or otherwise behind some IP-address-restricted firewall, then you definitely really want to avoid combining Access-Control-Allow-Origin-reflects-Origin and Access-Control-Allow-Credentials: true. (In the intranet case you almost always want to only be allowing specific hardcoded/whitelisted origins.)