Will CORS prevent a browser accessing an URL? - asp.net-core

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.

Related

When to choose: CORS vs DPOP?

While CORS and DPOP very different mechanisms, don’t they effectively do the same thing?
i.e. prevent unauthorized access to a resource server?
Why choose one over the other?
CORS does not prevent anything. It's used to selectively reduce security and allow servers to tell clients on other origins which requests they are allowed to make.
dPop is a way for a client to proof that they hold a private key when authenticating with OAuth2, without disclosing the key.
They are completely different mechanisms, and mostly unrelated. Lots of security features ultimately help prevent things from being "stolen", but you can't cafeteria-style pick the security feature you like. Chances are you need to be aware of all of them. Most are complimentary and the ones that are redundant are typically still used anyway (see 'Security in Depth')
No, the outcome of these two is not the same. CORS does not "prevent unauthorized access to a resource server". Thanks to CORS you might block some unwanted access from malicious code that is running in a browser on a domain that you didn't authorize to call you. Still, CORS relies on the browser to block any requests/responses that do not follow your CORS policies. Anyone can still call your endpoints bypassing the browser and having CORS configured won't stop them from doing so. With DPoP you authenticate the caller, so you can authorize access to your endpoints.

allow request from the code of one website only

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).

Access-Control-Allow-Origin issue on BulkSMS

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).

How to test CORS with Mule

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/

Securing the API exposed in chrome extension

Current State :
I am working on a chrome extension. My extension makes a request to my web-server and shows the results fetched.
Disadvantages :
I am exposing my APIs, so any third-party , not necessarily, owner of the extension may make a number of requests on my server. This will allow him access to all my data
This can also lead to my server crash, if the requests are made very frequently via bots.
So, is there any way that can authorize that requests made to the corresponding server handles are via the chrome extension only. Can it be done by setting some cookie and checking them before sending results ?
Thanks !
No, you can not ensure that only your Chrome extension is making the requests. Once your code leaves your control (i.e. the client has it), there is no guarantee that it isn't tampered with or reverse engineered. What you can do though, is make the user log in before accessing your API.
By authenticating, you aren't verifying that the user is using your Chrome extension, but you do have someone to blacklist if your server becomes the subject of large traffic. You can have the user of the chrome extension create an account one time and then the extension can send those credentials to your server with each request.
You may be tempted to try things like embedding a secret token or passphrase, but this will only stop the lazy attackers. Furthermore it may give you a false sense of security. Go with authentication if you are worried about Denial of Service attacks.