Lessons I Learned Using Proxies
I have been building a lot of applications recently using a variety of proxies. The reason for this lies in the choice of backend infrastructure for many of these projects. For those projects where I am reusing a number of backend services, a proxy + rewrite rules = a new clean API. For other projects where I am using existing services for multiple clients, proxy + cross domain headers = publically accessible data services. And for those applications which I'm moving from one cloud provider, proxy + request rewriting = search engine link survival.
In all of these cases, the ability to reuse existing services, be they internal or external, drives the need for a proxy. It allows migrating versions of APIs and entire applications across wildly divergent infrastructures in a controlled manner. It is a bit of a joke, that all problems can be solved by adding an additional layer of indirection, but in these cases it is the only reasonable solution. In cases where same origin security measures help protect the user, they also dictate a style of infrastructure. But as one mashes up more and more services, this infrastructure imposition becomes an obsticle that reduces the viability of entire classes of application.
- mashups of public data without resorting to JSONP
- central shared services by 3rd party vendors without DNS and cookie games
- mobile applications that host data locally and remotely based on network connectivity
From my point of view, there are very few good same origin solutions that properly protect user data. Making XHR requests to alternate origins via a proxy gives the programmer some control, but robs the user of knowing what is really going on under the hood. Some times it really pays to have separate domains for different types of cookies. Take for example an Oauth style service, which brokers capabilities like and LDAP server for mashups. Not exposing those cookies to every proxies service becomes the job of the engineer who configured the proxy. This makes it difficult to successfully offer that sort of service in a trusted fashion. This is why the SAML model is such a pain to wrap your head around. The point of validation must remain with the client, and not be controlled by a middleman with a clever proxy.
In the end, datagrams are datagrams, and the entire network relies on a series of proxies. We can use these proxies to drive application logic, and to supplant a good deal of what people do in application code. But using these services also exposes us to new and exciting security concerns. Trusted origin is meaningless when the origin is a middleman. Security and applications that rely upon those would do well to push against such flawed security models, and focus more on applied cryptography. Validating and verifying the integrity of the data must become the job of the client application as well as the server.