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).
Related
I have a keycloak client sample-application. It has valid-redirect-uri https://sample-application.mycompany, a frontend service. This frontend calls backend service, sending JWT token in http header. Backend service checks allowed-origins in this JWT token. https://sample-application.mycompany is there, so everything works fine in production.
"allowed-origins": [
"https://sample-application.mycompany"
]
Now we are doing some e2e tests, and we are calling this backend, but from a different place - http://jenkins.mycompany. We have a proper JWT token, but backend service fails on allowed-origins validation, because http://jenkins.mycompany is not there.
My options:
add additional valid-redirect-uri http://jenkins.mycompany to my client - I don't want to do that, adding testing stuff to production clients seems bad
make copy of a client sample-application-testing, with additional valid-redirect-uri, use it for tests, delete afterwards
tried using server's private-key to generate my own JWT with extra entry in allowed-origins, but it failed later, because server validates this token
tried some magic with setting different Origin headers, but it seems impossible, browser protection I guess
Is there any other possibility?
Edit - the validation I'm talking about, checks if Origin header is in allowed-origins list. To be clear: this is not something I invented myself. This validation comes from keycloak-spring-boot-starter, here is the relevant fragment: https://github.com/keycloak/keycloak/blob/17117820cc14f87f5990ddce80ef38a0e2e7f314/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/AuthenticatedActionsHandler.java#L126
Keycloak allows one to add multiple multiple Valid Redirect URIs as well as multiple Web Origins. One of these should allow you to add the URL for your test server and have it appear in the Allowed Origins in the JWT.
More commonly, test environments will have their own copy of production servers so as not to interfere with production operations. This is pretty standard. For a CI/CD setup, it makes more sense to use some kind of a stub or mock validator (something that can be spun up locally) to avoid setting up a server entirely
Below is a screenshot of the settings in the Client configuration in Keycloak 19
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.
According to my Google API console my top referrer is https://www.googleapis.com which I assume is normal, but it's followed closely by http://blocvox.com which I don't know what they are and I am suspicious as to why they are consuming a lot of my requests and jeopardizing my capped usage.
How can I prevent this referrer from accessing my API?
Note: I am not using an API Key (which does support the blocking of referrers) I am using the oAuth method.
The details depend on what your API is written in, but most popular Web frameworks allow you to look at the referrer value for the HTTP request. You could go further; most Web front-end servers allow you to filter/discard/reject/redirect queries based on the referrer field.
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.