Reverse Engineering Raises Ethical Aspects of Using Private APIs

A recent inquiry on Hacker News questioned the ethics of reverse-engineering a private API, and what should be done with it next. The question is a valid one, with opinion split over whether to publish the hack, allowing developers to create better applications through third-party integration, or to inform the company of the security breach, risking the closure of the API.

This particular hack is for a website that has over 10 million users. It gives access from third-party clients, allowing you to access your own data on the website, so there is no malicious intent. And while the hacker ponders what to do with the code, this is another example of how private APIs can be exposed to hacking.

There are several routes to cracking an API, the most obvious of which is simply down to service providers publishing far too much information in their client-side JavaScript. And associated mobile applications are notoriously easy to reverse engineer, leading people to dismiss the ethical worries of doing so.

One way to do this involves debuggers that watch what a native app does, then deconstructing the processes involved. Another route to cracking an API is the HTML toolkit for Ruby, scrAPI, which uses predefined rules for scraping object information from HTML content.

So while many people discuss the ethics of reverse-engineering and debate what should be done with the findings, the real issue for developers is the fact that APIs are so insecure to begin with.

Be sure to read the next Hacking article: MasterCard Announces Global Hackathon With $100,000 Prize

Original Article

I've reversed-engineered a private API, now what?