I am thinking to add Referrer-policy header in my app. Setting this header to :-
Referrer-policy - origin when cross origin
will send only base url (http://www.example.com) in referer header to all the third parties.
Is there any chance that this might effect Google-Analytics tracking ?
AFAIK Google does not use HTTP referer header field. It uses it's own Document Referrer dr field which is initialized as:
This field is initialized by the create command and is only set when
the current hostname differs from the referrer hostname, unless the
'alwaysSendReferrer' field is set to true.
And you may change it by: ga('set', 'referrer', 'http://example.com')
Related
I’ve setup the react UI in Cloudflare Pages with custom domain https://ui.example.com. There is a login page that allows users to key in user name and password. Once they’ve supplied the info, it will use axios to make a call to an API that is hosted in Cloudflare Workers https://apis.example.com and from there I’ve written sample codes to return Set-Cookies header with the “secret-token” value.
Since Pages and Workers reside in different domain, so I’ve configured Workers to supplied the following values to the API response, in addition to Set-Cookies header-values:
"Access-Control-Allow-Origin": "*"
"Access-Control-Allow-Methods": "*"
"Access-Control-Allow-Headers": "*"
"Access-Control-Expose-Headers": "Set-Cookie"
But when I check the response headers by using script (console.log) written in my login.jsx, it only contains content-length and content-type. But when I check the response from Chrome (Developer Tools’ Network) in my case, those header-values above exist.
How can I get the response’s header values from the axios call in this case?
You will need to use a different header name.
Set-Cookie is a forbidden response header, which means JavaScript is not permitted to read this header. The browser handles this header (adding the cookie to cookie storage) and then removes it before JavaScript sees the response at all.
Instead, try inventing your own header name, like X-Secret-Token.
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.)
I'm using Restangular. I would like to get full response so I set
Restangular.setFullResponse(true);
but then I discovered that my custom headers does not work. Documentation for setFullResponse() method says:
in order for Restangular to access custom HTTP headers, your server must respond having the Access-Control-Expose-Headers: set.
I would like to send my custom headers but I don't want to change server settings. Is it possible?
If I leave default settings i.e.setFullResponse(false) there is no issue with custom headers. Is there another solution except changing server settings?
The sentence you cite from the setFullResponse() docs is about what headers from the response your Restangular app will be able to access. And what that is saying is, it’s not possible to access most of the headers from the response unless the server’s already configured to send the right response-header names in the Access-Control-Expose-Headers header.
Without the server setting any value for that header, the only response headers that browsers will let you access from client-side JavaScript in your web app are the Cache-Control,
Content-Language,
Content-Type,
Expires,
Last-Modified
&
Pragma response headers.
See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name for the spec on that.
I would like to send my custom headers but I don't want to change server settings. Is it possible?
If you mean you want to send custom headers in a request from your client-side Restangular code to the server, please provide more details about exactly which custom headers you want to send.
There too though, there’s another CORS header your server must send in the response: the Access-Control-Allow-Headers response header. If the server isn’t configured to send that with the right header names listed, then your request will fail. The reason in that case is, you will hit https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests.
I have very basic question regarding the "Access-Control-Allow-Origin" header.
Assume that we have a website "www.siteA.com" that will be doing the CORS to another site "www.siteB.com" and the "Access-Control-Allow-Origin" on siteB is set as "www.siteC.com" only.
When user via browser access siteA and it tries accessing content from siteB, what will the response look like?
Will the request be blocked at the server level
or
will it send the entire response with "Access-Control-Allow-Origin" header set to "www.siteC.com" and will be blocked by user's browser? (i think the first is the correct one)
When user via browser access siteA and it tries accessing content from siteB, what will the response look like?
The same as any other response from the site.
Will the request be blocked at the server level
No. CORS is an instruction to the browser that it should not apply the Same Origin Policy to the request. The server can't (reliably) tell where a request came from to block it at the server level.
will it send the entire response with "Access-Control-Allow-Origin" header set to "www.siteC.com" and will be blocked by user's browser?
Yes.
will be blocked by user's browser?
Yes, because only www.siteC.com domain can access the resource according to your Access-Control-Allow-Origin header. They would send back;
Access-Control-Allow-Origin: http://www.siteC.com
You can find answers the questions about the Access-Control-Allow-Origin header via this.
We have a site where we are using cookies for tracking purposes. Now we are thinking in changing the domain of our site but we will want to still recognise User's sessions from the old domain. Is this possible?
You can't retrieve cookies that belong to other domains. As a workaround (in case you can still use the old domain); by creating an iframe inside http://newdomain.com from http://olddomain.com, you can get cookies and send to parent via postMessage.
Cookies are affected by same origin policy but you can bypass it with CORS (Cross-origin resource sharing).
CORS is a play between browser and server.
Basic idea is allow ajax request to cross domains but you can use to share cookies(security measures should be taken).
Browser send a request with Origin header.
If the server allows the request then it reply with Access-Control-Allow-Origin header with the value of origin.
If the server doesn’t reply with the header or don’t match Origin with Access-Control-Allow-Origin browser disallow the request.
But it doesn’t send cookies or something like that by default(you have to add “allow-credentials” extra header).
With CORS you can share the session between domains adding to new domain server the following headers:
Access-Control-Allow-Origin: https://original-domain.com
Access-Control-Allow-Credentials: true
More info about CORS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
http://quickleft.com/blog/cookies-with-my-cors