I am using Anypoint Studio 6.1 and Mule 3.8.1 and have a mule RESTful application that I want to stop CORS requests from being accepted by the application.
The application has been setup to do this but what is the best way to prove this is working?
From what I have read so far, the examples build their own application and I would just like to do something like send a request configured as a CORS request in Postman. How can I do this?
Thanks
I want to stop CORS requests from being accepted by the application.
I would just like to do something like send a request configured as a CORS request in Postman
You mean you want to block cross-origin requests just from Web applications running in browsers?
Given that browsers are the only tools that enforce CORS restrictions, and they only do it for requests from code running in actual Web apps—not for requests from extension such as Postman that aren’t bound by the same-origin policy that Web apps are—then you’re not going to be able to use CORS to block requests from Postman or from code not running from a Web app in a browser.
The application has been setup to do this but what is the best way to prove this is working?
Confirm the service isn’t sending an Access-Control-Allow-Origin response header—which it never would be unless either it were explicitly configured to do that or it’s built using some server-side programming environment/framework that adds Access-Control-Allow-Origin by default.
But since browsers are the only tools that are ever actually going to block cross-origin requests due to lack of Access-Control-Allow-Origin, you really can only test the blocking in a Web app.
Otherwise you can at least test outside the browser to see what response headers are returned by the server the requests are sent to. The main thing to do in that case is to be sure the request send an Origin header (some servers only send Access-Control-Allow-Origin if a request includes an Origin header—because browsers are the only tools that automatically send Origin.
So, using curl for example, you’d want to do this:
curl -H "Origin: https://example.com" https://service.to.test/
Related
I am building a private API which provides some data, I have already set CORS to only allow requests from my website, and that works, but there is a problem: a user can make the request with the chrome console from my website to the API and that request will succeed since the API has no real way to tell if the request comes from the code i have written.
So my question is: is there any way to tell that? is there any way to prevent users from making that request from my website to call the API and bypass the CORS?
You need to update your request model so that requests to the API come from the web server itself, rather than from a users client.
That way you can add authentication to the API and only allow requests that come directly from your web server. Then web server can then display those results to your users.
CORS is not a method for checking/enforcing authentication or authorisation. It is purely an additional security control to protect against browser-based security vulnerabilities (XSS etc).
If a activate CORS on my .NET core application, will then users be able to access a endpoint by putting an URL in their own browser (for e.g. https://example.com/api/Account/ExternalLogin?client_id)? Or does CORS only preventing javascript to make requests?
CORS is a mechanism enforced within browsers, not servers. The server can indicate to browsers what should be allowed, but ultimately it is up to the browser to enforce that. Hence, servers should always authenticate and authorize every request regardless of CORS.
To answer your specific question, yes, any client can attempt to access any endpoint on your server. Only cooperative browsers will prevent that in certain circumstances. It's always possible to request a URL directly via the address bar, regardless of CORS.
I've setup proxied authentication for RStudio Server.
RStudio Server is redirecting to a middleware implemented using Express JS
The middleware creates a request to the authentication server and then parses the response from it.
Then the middleware adds the X-RStudio-Username header to the response, which is a re-direction to the RStudio. However, the header is added to the response from the middleware, and then the browser doesn't keep it when it redirects to RStudio Server
Since the browser request doesn't have the required header, RStudio requests the authentication again creating an infinite loop
How should I approach this case?
What would be the best way to add the required header for RStudio Server?
The browser won't add this header for you. You need to add it in the layer that proxies traffic through to RStudio Server. If you don't have such a layer already, you will need to add it using e.g. Nginx. This layer could authenticate the request using whatever mechanism your auth provider supports and add the X-RStudio-Username header (which we recommend renaming for security reasons).
Since you're using RStudio Server Pro, our support team would be happy to help you with this:
support#rstudio.com
You'll also be glad to know that we're working on SAML support for an upcoming release of RStudio Server Pro!
I am using Angular 5 to send post request to send SMS through Bulksms : http://bulksms.com/
When making the request from Angular (client), I am facing this issue :
Origin http://TTTT:4200 is not allowed by Access-Control-Allow-Origin.
How can I correct this issue in BulkSMS ?
Regards,
Your browser's same-origin policy is restricting your Javascript code from accessing a third party (i.e. api.bulksms.com in this case) in the way in which you hoped to do it - and CORS (Cross-Origin Resource Sharing), which is a mechanism to relax those restrictions, is not relaxed enough to allow these requests (from you as an untrusted third party) either.
Wikipedia Same-origin policy : "Under the [same-origin] 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, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page". The Wikipedia page contains some good examples of the sorts of malicious Javascript code uses that the same-origin policy tries to limit.
It is important to note that these restrictions are only enforced by browsers: HTTP client code that is not running under a browser typically doesn't care about any of this.
For development purposes, there are some tools that can make your life easier - for example, you could use live-server to run a simple HTTP server which serves up your static files, while also using its --proxy option to route requests to api.bulksms.com and solve your same-origin policy problem in the process.
For production, a typical solution is to route your AJAX requests, which are destined for the third party service, via your own server (the one serving up your Javascript files to your browser), or a reverse proxy (which would front both your own and the third party service). If there is a server side to your application, you can make the HTTP requests to api.bulksms.com from there, using an HTTP client, and then have your Javascript code talk to your own server, to indirectly make the requests to bulksms.com. This also gives you the opportunity to add authentication headers on your server side, without your Javascript code ever having to know them (e.g. if you have one bulksms.com account, and many users able to use that account via your Angular app, but who should not know your credentials). Similarly, you could impose limits on what your Angular users can do in this way (e.g. to limit the number of SMSs they could each send per day).
I have a client-side angular-js application. And I have a server-side nodejs API. The client-side and the server-side application are located on different domains. The client-side use API for getting or posting some data. Also the client-side needs to get images from the server-side and show them in a browser.
I use passport nodejs module for the authentication. I don't know which authentication strategy is better for me. I think that there are two types of authentication strategies: token-based and cookie-based. And I think that both types useless in my case:
If I use token-based strategies, then I should send Authentication header with a token in each request to the API. I can send headers in AJAX requests, but if I want to show an image that is located on the server-side I have a problem. Because a browser will not send headers in <img> tag.
If I use cookies, then I don't have the problem with images. But I have problems with AJAX requests. Because the session cookie is stored on the server-side application's domain. And if I send AJAX requests from the client-side domain, then I should send cookies with each request. I use XmlHttpRequest for AJAX and I should use withCredentials option for sending cookies. But in crossdomain requests browsers will send a preflight (OPTION) request before each AJAX request. And browsers will not send cookies with OPTION request. This is a problem for me because the server-side API could not make a correct response on an OPTION request if it will be not authorized.
What is the adopted solution?
It is important to understand the difference between web applications and web services. A web application serves markup, JavaScript, CSS and image files and often uses cookie based authentication (but can use any other implicit authentication mechanism). Any request the browser makes is automatically authenticated.
Web services on the other hand often use bearer token authentication. When a client in a browser, fat client or on a mobile device communicates with the API, it sends along a token in the Authorization header of the HTTP request. The header has to be explicitly attached to the request in the JavaScript or native code executing the HTTP request.
In Single Page Applications (SPA), the web application is missing and the markup, JavaScript, CSS and images are served from the browser without authentication. Only the requests to the web services are authenticated, typically using a JWT token.
In your case, if you want only authorized users to be able to download images, and other files, you should consider building a web application. Use a security protocol like or OpenID Connect to authenticate your users. Choose an authorization server that supports both OpenID Connect for your web application and OAuth2 for your web service.