If I make a XMLHttpRequest from somesubdomain.example.com to someothersubdomain.example.com, will that be consider as a crossdomain request? I mean, would I have to provide Access-Control- headers to make it work properly?
somesub.example.com and someother.example.com are different hosts. Therefore, they're subject to the Same origin policy.
Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. If there is a difference , the same will be considered as a cross origin request. Reference:
MDN
Related
Lets say I have my website named SiteA.com running on an Apache web server. I have defined the ff. below on my httpd.conf file:
Header set Access-Control-Allow-Origin "CustomBank.com"
Questions:
Does this mean only CustomBank.com can access my site (SiteA.com) directly? or does it mean only my site (SiteA.com) can access the CustomBank.com domain directly? I am confused if this setting is for inbound or outbound.
In reality I don't have any CORS requirement needed for my site, so I didn't implement the setting mentioned above, the one below shows up in my response header.
Access-Control-Allow-Origin: *
Penetration Testing team said this setting is overly permissive. Do I just need to remove it? if not what should I do?
It means javascript loaded from CustomBank.com can make requests to your site (the site whose configuration has changed) via XMLHTPRequest in the background.
Since XMLHTTPRequest will send a users existing session cookie with your site, malicious scripts could do all kinds of nefarious/misleading things on behalf of your user. That's why * is not normally a suitable fix.
The restrictions apply to other script-like invocations that are more esoteric that you can read about in the specs.
I'm using Ambassador Mappings created through a Helm chart in order to rewrite and forward a web request. The client has requested that we include the originally requested URL in a header when we forward the request.
Based on documentation, it looks like there are only two dynamic values I can set: %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT% and %PROTOCOL%, neither of which seems to solve my issue.
Are there any ways for me to set this header properly through an Ambassador mapping?
Thanks!
So I think we've found the solution. If you use Envoy's syntax and make sure that is forwarded through, you can use their REQ() function, to get the authority and path, to construct the URL. For example:
http://%REQ(:authority)%%REQ(:path)%
Here is the documentation for all of the possibilities you can use with Envoy through Ambassador's mapping: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#custom-request-response-headers
This article says:
With these added headers, Cloudflare passes on all HTTP headers as is
from the client to the origin.
However, there doesn't appear to be a standard way to get the Host from the original request.
Is there a way to do this, either via standard options or enterprise option?
I have a server REST API that answer some JSON response. I want to chunk it on the server to increase response time.
Is there a way for a reverse proxy like Apache or Nginx or any other, to intercept this response, and gzip the chunks, and send it back to the client as chunked?
I got something working by gzipping the content before chunking it directly inside my API server, and I'm just wondering if there's any other option available to me that would increase response time of my server.
I think that this is possible according to some other stack overflow questions that I have seen answered.
https://serverfault.com/questions/159313/enabling-nginx-chunked-transfer-encoding/187573#187573
According to the above, it is possible to disable proxy_buffering in your nginx configuration, and supports gzipping output if configured.
As noted in the page, there are possible disadvantages and you should test to ensure that this action is appropriate.
I'm keeping the backend API as a separate project from the frontend HTML5 app consuming it. I'm using Yeoman for the frontend development. Yeoman runs on localhost:3501 and the backend on localhost:3000. When I make the API request from the browser (using AngularJS's $http), I hit the same origin policy:
XMLHttpRequest cannot load http://localhost:3000/venues. Origin http://localhost:3501 is not allowed by Access-Control-Allow-Origin.
AFAIK, same origin policy should kick in only when making request across different domains. Why is it whining when we do a request from localhost to localhost (albeit to different port)?
How can I make this work and will this cause problems in production?
The ports also count for cross domain requests, therefore http://localhost:3000 and http://localhost:3501 are 2 different domains (from browser's point of view).
If you need both applications (client and backend) to run on different ports, consider using http://enable-cors.org/
According to W3C, "An origin is defined by the scheme, host, and port of a URL", so the different port is causing your problems.
Two possible solutions:
CORS (Cross Origin Resource Sharing)
Using JSONP requests
Both would require changes to your backend (I'm not familiar enough wo. CORS would probably mean the least changes to your frontend (I think AngularJS supports it out-of-the-box).