I'm writing a simple REST API, and I want to restrict access to my mobile-client only. In other words, I'm trying to prevent a malicious user from e.g. using curl to make an unauthorized POST request.

Of course, this is impossible. However, there are certain countermeasures that make it difficult for a hacker to succeed. Right now, I am encrypting all requests with a private key, stored client-side (obviously, this is not ideal, but the difficulty in reverse-engineering an iOS app will hopefully deter all but the most determined hackers).

One simple idea I had is to return the wrong HTTP response code for an unauthorized request. Rather than return a "401 Unauthorized," why not return e.g. "305 Use Proxy," i.e. purposely being confusing. Has anyone ever thought about doing this?


  Has anyone ever thought about doing this?


Yes, there was actually a talk about exactly this at defcon 21 (video, slides).

Their conclusion was that working with response codes as offensive security can sometimes result in severely slowing down automatic scanners, non-working scanners, and a massive amount of false-positives or false-negatives (it will obviously do little to nothing for manual scans).

While security by obscurity should never be your only defense, it can be beneficial as defense in depth (another example: it is recommended to not broadcast version numbers of all used components). 

On the other hand, a REST API should be as clean as possible, and replying with purposely wrong HTTP codes may be confusing for developers and legitimate clients (this is a bit less of a problem for browsers, where users don't actually see the codes). Because of this I wouldn't recommend it in your case, but it is still an interesting idea.
