No Access Control Allow origin error on 2 sub domains - javascript

I'm trying to make an ajax get call between the two following sub domains:
Target URL: https://qa.mydomain.com
Origin URL: https://myotherqa.mydomain.com
I'm receiving the following error:
XMLHttpRequest cannot load https://qa.mydomain.com/suggest?
q=foo. No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://myotherqa.mydomain.com' is therefore not allowed
access.
I'm using $.get() to make the ajax call
Both the websites are under the same sub domain and both 'https'.
What am I missing?
Thanks

Issue is related to web security aka Same origin policy.
Under the policy, a web browser permits scripts contained in a first
web page to access data in a second web page, but only if both web
pages have the same origin. An origin is defined as a combination of
URI scheme, hostname, and port number. - More info here.
The proper solution to handle this is to allow CORS on your server side.
An alternative solution is using JSONP for get requests.
You can find some common settings and more information at this site:
http://enable-cors.org/

The problem is with the server configuration the server is not accepting request from other domains for security concerns. Ports maybe different, enable the cors at the server level configuration. This will solve the issue.

Related

Do frontend and backend sub domain needs to be same to have the effect of CSP headers from https response?

Let's say I have a website "webapp.abc.com" and my backend is hosted on "api.abc.com"
Now whenever my Frontend (webapp.abc.com) calls an API of (api.abc.com) then I get some CSP headers in the response
Now my question is I am getting these CSP headers from a different sub domain (api.abc.com) than my Frontend (webapp.abc.com), so what will happen...will the browser apply this CSP header that i got from the response of "api.abc.com" or is it necessary to have our Frontend and Backend sub domain be the same to have the effects of these headers on my website
CSP is a policy for content, which typically has content type "text/html" and is rendered in your browser. An API typically serves data and a CSP doesn't really make any difference. There are however situations in which it can be useful, see https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#security-headers
In this case you will instead need to configure your Cross Origin Resource Sharing (CORS) headers. You will need to set at least Access-Control-Allow-Origin. You should not set it to * or just reflect the origin of the request if the data isn't public. You might also need to set other CORS headers such as Access-Control-Allow-Credentials if authentication is required. Please try to understand CORS headers before implementing as they are relaxing the security defaults browsers are applying for your data's safety.

Docxtemplater CORS policy on webserver

I am trying to build a little website where i need to use Docxtemplater. (https://docxtemplater.com/)
This is a node module used to edit word documents (.docx). In the docs (https://docxtemplater.com/docs/generate/), it is stated "Please note that if you want to load a docx from your filesystem, you will need a webserver or you will be blocked by CORS policy."
I have tried uploading my website to a host (https://www.000webhost.com/), but i get the error:
mathiastester.000webhostapp.com/:1 Access to XMLHttpRequest at 'https://docxtemplater.com/tag-example.docx' from origin 'https://mathiastester.000webhostapp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Does anyone have any clue on what is going on...?
Here is the website: https://mathiastester.000webhostapp.com/
Just like the example in the link you provided, your AJAX code needs to make a request to some server-side code running on your webserver, which then sends the request to docxtemplater, because docxtemplater doesn't allow cross-origin ("CORS") requests to it.
Simply put, a CORS request is an AJAX request where the request is sent to a different "origin" (combination of domain, port and protocol) than the one it is running from. These are disallowed by browsers by default for security reasons, but the remote server can, if it wishes, return response headers indicating to the browser that the request can in fact be allowed. docxtemplater doesn't do that, and the documentation you quoted is telling you not to make a CORS request to their servers. However judging by the error message you've shown us, you've done exactly that in your code.
See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS for more info on what CORS is.

Does Cross-origin resource sharing affect all clients that connect to a web method?

I have a web method that I want to call from my C# app and was provided with a Javascript example, showing how to call the method. I have established that running the Javascript from my desktop runs into CORS problems - i was able to run the sample when I put the javascript on the server and ran it from the same folder as the web method.
Will my C# app run into the same CORS issue? or will it be ok because only the browsers have the built in CORS security?
--Edit--
I've been using System.Net.Http.HttpClient and http://restsharp.org/
Am I correct in assuming that these two objects are wrappers around a web browser? and that they will have issues with CORS?
I really don't want to have to write Sockets code.
Due to security reasons browsers restrict cross-origin HTTP requests initiated from within scripts on the browser. For example, XMLHttpRequest follows the same-origin policy. That means a web application using XMLHttpRequest could only make HTTP requests to its own domain. This prevents application from being vulnerable to CSRF attacks. However, there are cases when applications need to access resources from different domain. This is when CORS comes into play to allow cross-domain requests.
Having said all that, your C# app should be able to call the WEB API without any CORS issues as long as it's a socket to socket communication (not via browser).
Some where in deep recess of my mind I remember browser related cors will always be blocked unless noted or changed like for example if you're in chrome and have the cors extension allow browser cors control, but on the server side, their is nothing preventing servers from interacting with one another.
but it depends on what is allowed on the headers
I'll try to produce some documentation that confirms that.
https://spring.io/understanding/CORS
The request includes an Origin header that indicates the origin of the client code.
The server will consider the request's Origin and either allow or disallow the request. If the server allows the request, then it will respond with the requested resource and an Access-Control-Allow-Origin header in the response. This header will indicate to the client which client origins will be allowed to access the resource. Assuming that the Access-Control-Allow-Origin header matches the request's Origin, the browser will allow the request.
On the other hand, if Access-Control-Allow-Origin is missing in the response or if it doesn't match the request's Origin, the browser will disallow the request.

Error in Ionic App's javascript: No 'Access-Control-Allow-Origin' header is present on the requested resource

guys!
I'm having some trouble with javascript in Ionic. I'm trying to make a request to another site, and I'm having this error message:
XMLHttpRequest cannot load https://svcs.sandbox.paypal.com/AdaptivePayments/Pay. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access.
My Ionic App have already the plugin whitelist installed and up to date, my config.xml file allow navigation and access of every location. I've tried also to execute chrome with security disabled and it didn't work either.
Could anyone help? Don't know what else to do.
By default, XMLHttpRequests are limited to same domain requests (i.e. request between localhost and localhost or request between paypal.com and paypal.com).
Cross-site XMLHttpRequests (like from localhost to paypal.com) are disabled by default as a security feature in modern browsers, in order to bypass this security feature, the destination server should explicitly allow cross-site requests and this is done by sending back a header called "Access-Control-Allow-Origin" with either * or specific domain as value, for example when a server replies back with the following header:
Access-Control-Allow-Origin: *
It is telling the browser of visitor that I'm accepting an XMLHttpRequest from any domain.
In your case, you are doing a request on https://svcs.sandbox.paypal.com/AdaptivePayments/Pay which doesn't allow cross-site requests (no Access-Control-Allow-Origin is present) and thus the browser is blocking XMLHttpRequest from going through.
You cannot test your http://localhost:8100 (LOCALHOST) to paypal services/api's that requires communication with your script, except if you use tunnel hosts, like https://ngrok.com/, https://localtunnel.me/. Your scripts that run in your localhost should be accessible to the world wide web, so that it is visible to Paypal.

CORS - Is it a client-side thing, a server-side thing, or a transport level thing? [duplicate]

This question already has answers here:
How does the 'Access-Control-Allow-Origin' header work?
(19 answers)
Closed 6 years ago.
I am trying to understand CORS. From my understanding, it empowers you to limit which domains can access a resource on your server. However, this doesn't seem like the full story. For example, I have a web service without CORS enabled. I cannot hit this web service from my web application via jQuery (the app is running on localhost). However, I can hit the web service from Postman. So, I'm a bit confused. Is there some extra client side work that involves CORS?
The server is responsible for reporting the allowed origins. The web browser is responsible for enforcing that requests are only sent from allowed domains.
CORS is applied to requests when an Origin header is included in the request. This includes requests made from JavaScript and POST requests. It's not applied all resources. The origin is the protocol, host and port that is making the request. Requests made by JavaScript use the origin that loaded the JavaScript, not the origin that it was loaded from.
When CORS is not enabled a browser will rely on the same origin policy. The same origin policy is only applied to scripts. The browser will only allow scripts to be loaded from same origin as the loaded page. The same origin policy is assumed when not origins are explicitly allowed.
An HTTP client other than a browser won't use either the same origin policy or CORS. Requests made from these other HTTP clients don't have an origin. Unless the Postman desktop app emulates a browser it will be able to make requests to any URL.
CORS and the same origin policy are needed because a browser does not implicitly trust the websites it visits to make requests to other websites. They don't protect the origin site, they protect the site receiving the cross origin requests. This is why the allowed origins are up to the targeted server.
Without these policies a simple script that repeatedly loads a website could be distributed by ad networks or script injection and then any browser loading the script would contribute to a denial of service attack on the website. With CORS and the same origin policy a browser will limit the impact of this script.
Another important protection CORS provides is to protect against Cross-site request forgery. It prevents a site from making some types of requests to another site. These requests would be made using any previously created tokens, such as session tokens.
CORS by example:
A web browser loads a page from www.example.com. The page includes a script that makes a request to www.example.org. The origin of the request is www.example.com. The browser either makes the request or sends an OPTIONS request first (the preflight request). When the server at www.example.org receives a request from an origin other than www.example.org it responds with a response header Access-Control-Allow-Origin which tells the browser the origins allowed to make requests. It may also respond with other headers like Access-Control-Allow-Methods and Access-Control-Allow-Headers that can restrict the types of allowed requests. When the browser is told what origins are allowed it will block future requests from disallowed origins.
It's a bit of both actually. Your browser will prevent CORS requests unless the origin of the request (i.e the referrer URL domain) is in a white list on the destination, or the destination approves all requests regardless of origin.
In both cases, the required header (Access-Control-Allow-Origin) is added which tells the browser that it's ok to send the request to the destination.
This ensures that people with malicious intent cannot send requests to another domain without the the user knowing about it.

Categories

Resources