I there a way on setting multiple origins on AWS API gateway. I went through documentation and you can set only one origin for CORS.
I believe we can only set one origin(or the wildcard) in Access-Control-Allow-Origin header. This is not a limitation of Aws API Gateway, this is just standard that Browser understands irrespective of which server/gateway.
We can always check incoming origin header from the request and if it is found in our list of valid headers, we can respond origin header value back in Access-Control-Allow-Origin header.
Related
I have rest api which is publicly available with REST API key authentication, but I want to allow private network to access api without authentication. Is it safe to add global CORS
Access-Control-Allow-Origin: *
Note that I am doing authentication in haproxy:
acl private_ip src -m reg -i (^127\\.0\\.0\\.1)|(^10.*)|(^172\\.1[6-9].*)|(^172\\.2[0-9].*)|(^172\\.3[0-1].*)|(^192\\.168.*)|(^::1$)|(^[fF][cCdD])|(0:0:0:0:0:0:0:1)
I read that setting CORS "*" could cause some security issues in case when there is IP authentication, but as I am not sure how "src" IP address in haproxy is obtained I can't be sure if this security risk is present in my case?
It is strongly recommended against to use IP authentication and a permissive CORS policy together.
CORS allows for script on a page served from one host to process a response from a call to a resource on another host when normally a well-behaved browser would stop script on the page from reading the response. For example where a page on webserver.com includes an AJAX call to a resource on api-server.com.
CORS is enforced by the browser, so if your attacker can make a call to your API then they are able to ignore your CORS header, and this is transitive to anything they can get another user to do by serving them a malicious page.
API authentication (whether by token or by IP) is a server-side protection that allows you to filter your response to the request. Consider the case where your attacker has access to your network. They can make a request to your API and your IP authentication lets them get the data. CORS is not the solution to that, but you of course secure your network well and only your users have access to it.
However, if the attacker controls a website (say, compromised.example.com) then they can send a user on your network a link to their page. When your user goes to the page, they are served a script that makes a call to your API. Because you permit the request based on IP, you provide the response.
This is where CORS comes in. If you have a header allowing '*' on your API responses, then the browser on your network will happily provide the requesting page (served from the attacker who is not on your network) with the response.
So the attacker has unauthenticated access to your API if they can get one of your network's users to browse to their malicious page and exfiltrate any responses that a user on your network can get.
I am using a third party https api and getting this error
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.
I am using firebase hosting on spark plan with Cloudflare.
and the api is called from a subdomain like xyz.domain.com
Not a full answer.
Looks like it's something on the server side that need to be set. You can either disable CORS on your browser (which is sub-optimal as other users may face the same problem) or do the setting on the server side. I don't know Cloudflare, but I guess (?) there is some way that you can set 'Access-Control-Allow-Origin' to '*', which would then fix it.
This project is on nuxtjs.
I don't think is important but maybe it can be some clue.
I need to get order detail information for using axios and below url.
/users/orders/d/20210806000349
but, very weird because axios doesn't request without cookies that url
of course i do set withCredentials: true already
when i change that url to /20210806000349 everyting is okay
someone help me about this?
I need more detail about domains but maybe api domain and nuxt domain are different. in this case you should care about CORS.
what is CORS
Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading of resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.
MDN
what happen if you request to foreign domain?
user agent send an option request to foreign host
foreign host send response whit some header
user agent looks to Access-Control-Allow-Origin header and if its value is not equal to your domain block request
if request's withCredentials be true look at Access-Control-Allow-Credentials header and if its value be true send request with cookie. otherwise send request without cookie.
figure out myself
get request also preflight options request if domain is different
but in this case chrome doesn't show up options request
i check this on firefox
Should I used custom HTTP Header to pass JSON web token or HTTP Authorization header in my RESTFul services.
I have already read Custom HTTP Authorization Header but could not understand clearly drawback, if I use header like - X-ABC-Token.
After reading REST Authorization: Username/Password in Authorization Header vs JSON body, I feel Authorization seems good choice.
If I use HTTP Authorization then I believe I can use scheme bearer to achieve this as mentioned in
rfc6750
Please suggest me what are the best ways to pass this token in each HTTP request.
You shouldn't expand the standard features of the protocol if the existent ones solve your problem. The correct approach is to define your own authorization scheme for the Authorization header.
You can do something like:
Authorization: MyCompanyLogin token="abcdefg...."
Browsers and proxies already know about the Authorization header. For example, responses to requests with an Authorization header are not cached or are cached just for one user.
In contrast, browsers and proxies don't know about your custom X-ABC-Token header. A proxy may return the same page to different users, even if that header is different. This makes it possible that one user sees the information of another user. This in turn can be disabled by using the header Cache-Control: private.
I am invoking one of my APIs using curl as follows(cross origin).
curl -H "Origin: foo.com" -H "Content-Type: application/json" -H "Authorization: Basic YWRtaW46YWRtaW4=" -v https://localhost:9443/api/v10/configs -k
I have not set the necessary cross origin headers in the server side. But the API call works. Why is that?
on server side API class, in the options call I am only setting the Allow header.
#OPTIONS
public Response options() {
return Response.ok().header(HttpHeaders.ALLOW, "GET").build();
}
The following headers are not set.
Access-Control-Allow-Methods:
Access-Control-Allow-Origin:
Access-Control-Allow-Headers:
CORS is a mechanism to enable cross domain requests but in the browser using AJAX. If you use curl you can do what you want ;-)
So in your case (using curl), you try to execute the request outside a browser. So you are free to do what you want! With curl, the request will be always executed and you will see the exchanged headers for example. This can be something helpful to see if you have the expected headers for CORS...
Hope it helps you,
Thierry
You may want to read HTTP access control (CORS) to get a better understanding of how it works, and the main purpose it serves.
Just some into snippet
For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests.
The W3C Web Applications Working Group recommends the new Cross-Origin Resource Sharing (CORS) mechanism. CORS gives web servers cross-domain access controls, which enable secure cross-domain data transfers. Modern browsers use CORS in an API container - such as XMLHttpRequest - to mitigate risks of cross-origin HTTP requests.
So CORS was introduced to allow for cross-domain access (from scripts) in browsers. How it works is that when a a request is made that requires cross-domain authorization, the browser first makes an OPTIONS ("preflight") request to look for the access response headers. If they are there, then it make the initial request. Otherwise there is a request error.
As an aside, I would avoid implementing CORS support in resource methods. I would instead use a filter mechanism so all requests are handled in the filter, instead of having to implement an #OPTIONS method for all endpoints.