Situation:
I have a production web server, let's say https://example.com, configured with CORS with limited set of allowed origins. The set does NOT include localhost origins.
On localhost, developers develop a page/module/whatever that needs to call the production web server via AJAX (even during development). To do that, they run Chrome with CLI arguments --disable-web-security --user-data-dir=chromeNoCors so that Chrome would send AJAX without Origin header.
The problem is that only GET requests are sent without the header. POST requests still contain the header, therefore the production server compares the header value (http://localhost:5678) with allowed set of origins and forbids access to requested resource.
Question:
Is it possible to somehow prevent sending of Origin HTTP header altogether?
I'm aware that there's a workaround to solve this situation by allowing "localhost" (or some specific host that developers will have to add to their /etc/hosts) to the set of allowed origins on production server but I'd like not to do this if possible.
if you guys use chrome try this extension
https://chrome.google.com/webstore/detail/requestly-redirect-url-mo/mdnleldcmiljblolnjhpnblkcekpdkpa
you can modify requests on the fly,even headers
I recommend that you setup a simple "proxy server" (short node.js or python script would suffice). Have this server forward all requests to your remote API server but delete the information about the origin in headers. This is a matter of simple regular expression.
This is simple solution that will be portable to different servers. On AJAX side, all you need is to change the hostname to localhost or IP of your testing proxy server.
Related
Since XSRF validation involves matching of cookie/token sent in the UI request with the request header as part of that same request, what are the options for testing locally?
So assuming I run my UI locally and I am pointed to server hosted in a different place, the cookie would never be able to read on localhost (since it is a different host). What is the best-practice in this case - is it adding logic on server to identify the Origin and bypassing the check if Origin is localhost ?
What I usually do in such a case is to use /etc/hosts and use a subdomain for my code running locally. E.g. the UI is run on www.example.com and the server is on api.example.com, then in my hosts file I point www.example.com to localhost.
If the cookies are not samesite cookies and the server has proper CORS settings, then in fact it shouldn't be a problem using them from localhost. Your UI won't have access to them, but the browser should send them together with any request to the server. (CORS should allow credentials and the http client of your UI should use something like a withCredentials: true flag)
I'm working on an Angular web application. I need to make a POST request with a XML body to a server I don't have control over. The request needs an Authorization header. I tried the following:
Send the request directly: It only works when the application is served on http://localhost. Otherwise, the browser shows the following error: Access to XMLHttpRequest at 'server.com' from origin 'my-server.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource..
Use a browser extension that adds the missing header to responses: Unsafe, because the extension adds Access-Control-Allow-Origin: * to responses from all domains and that header allows requests from any domain.
Disable browser security: I ran Chrome using this command: chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security. Works when the application is running on a HTTPS server. However, it's unsafe, for the same reasons stated for the previous approach.
Use a third-party proxy: Works for a few requests, but the server blocks the proxy IP because the requests of all clients pass through the same proxy.
My project requires to bypass browser security without compromising security for non-related domains. My project also requires a different IP to be sent to the server by each client. That's required so that if a client overuses the feature, it won't affect other clients.
Is there a way I can add Access-Control-Allow-Origin: my-server.com to all responses or add the header only for a specific server? Is there a way I can redirect each request to a different IP so that the server won't block all my clients? Are there any other workarounds?
For protection of end users browsers block requests to other servers. Yes, you can have a cors browser extension but that is a temporary solution.
You need to set up an endpoint on your server 'my-server.com' to consume your web application post requests. From there you can communicate with the server you don't own and set up your proper auth headers ect.
I am facing a strange issue. I have a java spring app running on the PORT 8080 and Angular app running on port 3000. While making the request its returning status 200 and can find response in the browser network tab, but console is throwing error XMLHttpRequest cannot load 'http://localhost:8080/apiname'. No 'Access-Control-Allow-Origin' header is present on the requested resource. origin 'http://localhost:3000/#/home' is therefore not allowed access. Is there any way to get this working without making any changes on the server side. Any help is appreciated
It sounds like you have one service on your machine trying to talk to another, and for whichever reason they don't identify as being in the same domain. Usually you will have to add a cross domain policy for domains that aren't within the same environment.
The Access-Control-Allow-Origin header is a CORS standard that instructs you who can send communication over cross domain policies.
You can only host one website on port 80, and it wouldn't quite make sense to have two sites. One SSL(443) and one HTTP(80) so this may be why it's in effect, are because of your ports.
For the simple answer, add the header into your server side response and be sure to add that domain and port, to your cross domain policy.
I'd encourage you also to try to look at why you're having to perform these communications. You could put the two services into one site and remove the need. That's your easiest answer for a non-server change.
Otherwise, you will have to add it. It's a security protocol. There are steps to remove it, but that would open you up to a myriad of security vulnerabilities.
Use the following link to read more, and you can use * as opposed to disabling for another approach.
https://enable-cors.org/server.html
Access-Control-Allow-Origin: *
The above header will allow all cross domain policies, implemented server side.
You can enable it in firebox by adding extension
https://addons.mozilla.org/en-US/firefox/addon/cross-domain-cors/
You must enable CORS headers server-side or use a proxy (own, or a simple service like crossorigin.me for development purposes) that serves proper CORS headers.
In order to enable CORS in Express.js app, please see cors middleware - for simple use cases, a single line of code is enough - app.use(cors()).
For desktop or in-app usage, you may ignore CORS headers if you like as you have greater control over HTTP client.
So I have an API deployed on a cloud service. For testing purposes I use various HTTP clients like Postman, Paw and RestClient to send request to my API and they all work just fine. But when I send an AJAX request from Browser either with jQuery, reqwset or any other, I get the following error:
XMLHttpRequest cannot load
{https://url/to/my/api/on/google-app-engine}. No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:8000' is therefore not allowed
access
So Why does an HTTP client work but browser throws an error? Is there any risk if I enable CORS on the server?
This is because of the “same origin” policy of web browsers. This prevents a script on one website to make requests on another website on your behalf.
Enabling CORS is safe as long as you trust the allowed client, which is probably not the case if the client is at localhost (since you have no control on localhost in general).
Special case: if there's no way for a client to perform changes on the server's domain, then it's safe to enable CORS in general.
I have a NodeJS server running on my machine, and I am trying to access it with ajax from a website running on the same machine. I have getting a cross domain error though:
XMLHttpRequest cannot load http://localhost:3000/games. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
I have access a different api on this machine, running with php, which the address is
http://localhost/games.
My thinking is that because the nodejs server is running on a different port to apache that is causing the cross domain issue?
Any insight would be great, im new to api development and not sure where to go from here.
It has been suggested to me that I should try use JSONP, but im not sure if this is technically needed, since the api is running on the same machine?
An origin is defined as a combination of URI scheme, hostname, and port number so you're indeed breaking the same origin policy performing a XMLHttpRequest from http://localhost to http://localhost:3000
I'm not very familiar with nodejs but I see five options:
Obviously the easiest thing would be run everything on the same port, not sure if this is possible or not on your scenario.
Use JSONP (only valid for GET requests)
Implement CORS headers (it has some compatibilities issues with IE <= 9 + other corner case anomalies)
Implement a proxy to always communicate to http://localhost from client. Let the proxy deal with http://localhost:3000 and return response to client.
Use an alternative to perform cross domain request as XDomain
Since you need to be able to send POST requests, your only options are:
Implement CORS
Reverse Proxy
php proxy (or whatever language you are using for serving html pages)
The easiest would be to implement CORS if you are using express. Most of the work is done for you, all you would need to do is include the cors module and attach it as middleware.
Reverse proxy is the next solution to look at. What it does is it takes all requests to a given domain or domain/folder and reroutes them to the specified domain, in this case your node server running on a different port. For example, you would route all requests to http://localhost/api to http://localhost:3000. Research Reverse Proxy for the webserver you are using.
The third solution would be to have the webserver serving html also send requests to the node server. I consider this to be a bit too hacky for my tastes because the above two solutions are easy to implement and don't add additional code to the html webserver. However, if you didn't own the target webserver, this would be the only option if the target webserver didn't support CORS.