Show HN: Include this JS library to enable cross-origin requests | Hacker News Reader

Show HN: Include this JS library to enable cross-origin requests

github.com

20 pointsodedgolan30 comments

Overwhelmingly terrible idea. Routing your web site traffic through an entirely unknown third party server. Overwrite the global XMLHttpRequest object.

Please tell me this is a joke to show off terrible security practise?

Regrading overwriting XMLHttpRequest, if it works - it works, and if it breaks it can be improved, this is why it is open source. It does not reroute your site traffic just your cross-origin site traffic, which practically does not exist without this library. Yes it can be used to do bad thing but also opens up the opportunity for mashups, external content integration, api calls and more.

Routing all your x-domain requests through an unknown third part via vanilla HTTP? What could possibly go wrong?

It's just your cross-origin traffic, which is not possible without this library, everything else will behave exactly the same.

And whoever is running this proxy will _promise_ not to log any sensitive information (API keys not the least) or otherwise use/modify the response for their own ends?

Not to mention that the API endpoint is HTTP only, meaning everything is broadcast in the clear.

Also, cross origin requests are perfectly possible without this library, it's precisely why we use JSONP and CORS.

When it comes to security, this library is a collection of anti-patterns. As well as the JS anti-pattern of not overwriting native objects, such as XMLHttpRequest in this context.

Please don't use this. JSONP and CORS are the accepted methods for cross origin requests.

You can only use JSOP and CROS with sites you have control over or are designed to behave and support external requests. It makes it very very limited!

"You can only use JSOP and CROS with sites you have control over or are designed to behave and support external requests."

That's kind of the point.

It limits the thing you can do. This library allows you to easily get and display content from any external source.

Those limits are a security measure to protect against XSS and CSRF. Intentionally weakening your site security isn't a good idea for most people. Your mash up site evidently uses this to get around same origin policy without the cooperation of targeted sites. It would be interesting to know how you plan to mitigate those risks.

How is this remotely trending? Yes, HN, let's vote a MITM attack to the frontpage. This is a terrible idea.

Yes it allows you to do back stuff. But it also allows great things as mashups, retrieving external content easily etc.

Tell you what. Since I'm not a big fan of the lynchmob, here's the only positive critique I'll give you: proxying isn't an altogether terrible idea. It's not my first go to, but it does have it's place. HOWEVER. Allowing a third party to manage it, is. If you genuinely want to create some buzz and interest, source the serverside of this, and write some docs up how to deploy it to AWS, Heroku, etc. Bundle the JS with that. That'll be infinitely more useful than this service.

You're asking that I trust you will not modify the response in any way shape or form. The very nature of software dev mandates that I do not trust data that is not my own; and even then, verify it. You're asking quite a lot here. This is by all points and purposes, a man-in-the-middle attack vector.

OK, it is a trust issue. However you can use this library and change the proxy url to your own server and still get the benefit of the fact that you don't need to rewrite external requests and just use jQuery.

At that point, if I wrote my own proxy server, I'd drop the JS altogether and just request a proxy link. I know what's cross-origin in my code, so if I wanted to mitigate it with a proxy, I don't need the additional library. Still say your best bet is losing the JS and opening up the server. I mean, what's going to be better here, telling everyone "it's a trust issue", or passing on a relatively simple self-hosted proxy server made specifically for CORS-faking? Else, my big trust question is "why exactly do you WANT me to forward my traffic through your black box server?"

This is just a proxy. If developers wanted to go this route they would set up the proxy on their own server instead of routing it through a 3rd party.

It's possible, we just make it easier. This library also make it seamless (you can still use jQuery.ajax). They can use this library and just change the proxy url.

If you need to ask why it is bad to route traffic through an untrusted third party over HTTP, for the love of god stop building web applications. This is not the right tool for the problem it's trying to solve.

"untrusted" is the issue here, and trust is built over time. In the meanwhile you can use the library and implement the server side.

I would let the users know that requests get routed through a server you control.

It only goes through our servers if it's cross-origin. Normal http same-origin requests are left intact (and you can see it in the code). It's stated on the README but perhaps it should be more apparent.

I'll probably never use this library for anything, but I've submitted a pull request that takes out their 3rd party proxy and merely suggests it in the error that is thrown if you don't define your own. https://github.com/TOMODOcom/TOMODOkorz/pull/1

Seems a cool idea to use with mockups and prototypes, but an awful idea to use in a serious product.

Why? remember your product will function exactly the same. It just makes more thing possible.

No, it will not function exactly the same, because it sends stuff through your server. That is a very important difference.

Leaving my front door open when I'm on holiday also makes more things possible. That does not mean I will like those things.

If you are working on super sensitive website for the NSA, I totally agree. YOU SHOULDN'T USE IT.

But if you have a blog and you would like to constantly display some specific content from a different webpage via ajax it seems like the easiest & most simple solution.

I don't doubt that your service works with the best intentions, but why should I open a security hole in my application, when I can easily avoid it by writing my own proxy and keep it private?

What happens to my application, if your service goes through a DDoS? What happens to my application, if you suddenly decide to close your service?

I'm pretty sure you can use these arguments about other services, but this service exactly, is not worth the risk.

Don't take me wrong… I would use your service in any proof-of-concept/mockup/prototype… It really helps a lot in those use cases, since is one less thing for me to worry about.

I just don't trust it enough to use in production.

There is a level of trust needed. However, you can use this library, change the proxy url and implement the server side yourself.

If you trust Yahoo!, you can try proxying requests via Yahoo Pipes for Cross-Origin support. Not that I recommend it, though.

[1]: https://gist.github.com/psychemedia/316660

Reply on news.ycombinator.com