We wish to build a web app that will consume our REST API and looking for a way to circumvent the Same Origin Policy security feature.
We have a REST API which is served from api.ourdomain.com from SERVER_1.
We have a Web App which is server from dashboard.ourdomain.com from SERVER_2.
The Web App communicates with the REST API using ajax calls that include GET, POST, DELETE and PUT requests.
At some point in the future, we might consider allowing 3rd party sites to access the API from their own sites and domains.
Due to the Same Origin Policy security feature of the browsers, these requests are not allowed.
We are looking for ways to circumvent this.
Solutions we have encountered:
Tunneling the requests through our proxy. This will slow down the app and requires more resources.
JSONP - Will only work for GET requests. We do not wish to overload the GET requests with post/put/delete capabilities.
Using an iFrame with document.domain set to the same domain. Will only work for sites under ourdomain.com.
Frameworks such as EasyXDM. Seems like a good solution.
Thank you!
I don't know EasyXDM but I have the same architecture you are talking about in more than one application. We use your suggested solution (1). In my opinion proxying the requests through a common subdomain is the cleanest solution. I don't think that this is a performance problem. Many sites use something like nginx anyway to do some sort of reverse proxy (as cache). You could easily tunneling your API through http://[yourhost]/api and the rest of the HTML, CSS and image resources through other paths.
Related
I'm having an issue with a project I'm working on. I have a Vue client which does API calls to my backend which is written in .NET Core 3.1. Both these applications are deployed on diffent servers.
Now the problem is that my backend server does not allow me to do API calls straight from the browser. So I have to do some kind of 'redirect' on the client server to reach my API.
So for example:
If I call backend_server/api/values I get an error (Firewall).
I think I should make like a second API or something, but I'm not sure how to handle this issue.
Does anybody have any experience on this? Any help is welcome!
Kind regards
You can have multiple options here
Remove the firewall rule -
This will allow your API to get hit from browser. If firewall is not managed by you you can't do this
Add IP or Port exception rule in firewall -
Instead of deactivating the entire inbound rule on server, you can allow specific ports or IP on firewall. Again if you have control on firewall
Create Proxy API -
Another way is you can create a middleware API that forwards your request and acts as a proxy. This will suffice performance, resource, time and compromise security. I recommend not to do this, But it's easily possible in .NET Core
Specify CORS policy -
If your Vue.js and API originates from same origin (IP), You can configure CORS in server which will restrict access to API only from same origin. That means only www.google.com can access GoogleAPI, Likewise. This will protect the API from other origins
Tunnel via VPN -
If security is a concern, Use a VPN service to tunnel your API requests. This can't be possible for every client using your web service.
The best way is to open a specific rule on server for your application if possible. Writing a proxy in between will have lot of disadvantages although can be accomplished.
I'm build a apache cordova mobile app that consumes a specific google api.
What i'm planning to do is consume google apis directly from the app.
Is there any benefit to create a proxy service that consumes google apis and have my app consuming the proxy api ?
I ask because it seems a common practice, but i don't see any benefit.
Is it a best practice or a bad practice ?
If yes maybe a legacy system, maybe yes to do transforms, but now in days, so many "more modern" RESTful API providers have pretty nice client libs. Seems like one more link in the system to fail if I was proxy, and extra load to deal with... (I wouldn't proxy requests to youtube or some storage account for large static assets).
I do find it nice to proxy my own APIs if it's not public. It usually helps to remove the whole CORS mess and eliminate any performance penalties from extra preflight requests, but most public APIs don't have heavy CORS issues since they are, well public and don't have limited allowed origin.
Even simple JS libs hosted on CDNs like JQuery, I usually leverage 3rd party CDNs if available rather than bundle and host on my own CDN through Azure or Google that I have to pay for.
I have a web app that will reside in a secure site (HTTPS) that needs to access other sites using http using javascript libraries.
Due to very valid security concerns this is not allowed in modern browsers but I can't control the other http sites that I need to access.
My question is: What are my best options for this (and only) particular case? I would like to be pointed in the direction of a minimal solution to the problem if possible.
Thanks!
Found the solution with Titanium Web Proxy.
Thanks
I'm designing a REST web API, but noticed something weird lately.
Apparently some proxy servers are blocking specific HTTP request methods. In my case the PUT and PATCH methods which are crucial to modify resources. This partially breaks the functionality of the API I'm designing...
Is there a good way to bypass this problem without breaking the RESTful architecture constraints? In my opinion there isn't, because fully using the HTTP verbs is advocated when designing a REST web API over HTTP...
You have a few options:
Ignore it. People who willingly break the(ir) web (experience) using a malconfigured proxy server will have to deal with the consequences themselves.
Ask the proxy administrators to whitelist your host or the methods it accepts.
Rewrite your API, "breaking" REST principles.
Use HTTPS, so the proxy will only see the connect method.
The question is as simple as the title. I have a webapp (I have no clue as to what technology it was built on or what appserver it is running on). However, I do know that this webapp is being served by an Apache Server/ IIS Server / IBM Http Server. Now, I would like to have a plugin/ module / add-on at the web-server end, which would parse/truncate/cut/regex the http response (based on the requested url's pattern), and mask(encrypt/shuffle/substitute) a set of fields in this response based on different parameters(user's LDAP permissions in the intranet / user's geo-location if on the internet, etc) and send the altered response back to the user.
So, Is there an easy answer to creating such plugins/modules/add-ons? How feasible is this approach of creating extra software at the webserver, when you want to mask sensitive information in a webapp without modfying the web-app code? Are there any tools that help you do this for Apache?
And, finally, is this just a really crazy thing to try?!
Each webserver will have its own way of doing so.
There is no universal plugin architecture for webservers.
In IIS you would write an HTTP Handler or HTTP Module, or possibly an ISAPI Filter. You can also directly interact with the http response using the Response object exposed by the HttpContext.
With apache, there are different modules that can do what you want (mod_headers, for example).
I don't know anything about WebSphere, but I am certain it also has similar mechanisms.
What you are asking is required by most web applications, so would be either built in or very easy to do.
The easiest way is to add a plug-in using the web application container. For example, if it's Tomcat, you can add a filter or valve.
If you want to plug-in to the web server, you'd need to write a custom module using the API of whichever web server is being used.
If all else fails, you could always wrap the entire server in a reverse proxy. All requests would go through your proxy and that would give you the opportunity to modify the requests and the responses.