I'm building an iPhone application that has to communicate with a MySQL database through a PHP API.
Now obviously, I don't want anyone to have access to my database. Therefore, I want to put some decent security in the API and the app.
After some research, I found out that this may be a good way:
Building Secure Public API with PHP/MYSQL
It basically says that the code performs some math on the variable entered by the user on the app side. This math returns a value. Then, you perform the same math on the variables on the API side. if the values are the same, you know that the API gets save request.
The problem is, the SO post I linked to above is about an PHP application AND API. I have an app written in Objective-C and a PHP API, but I want to perform the same kind of trick.
Is there a way to put this kind of security into a service with a Objective-C app and PHP API? if not, what would be a better idea to secure my service?
A couple of things to consider as you try to select an appropriate set of security practices.
Does your proposed scheme keep any sensitive information confidential? Will it prevent me as a malicious third party from reading all of your users' communication even if I cannot control any of the messages or otherwise impersonate them? As proposed I don't see anything that would prevent an attacker from watching these requests and responses. Maybe that is not a concern here? If it is requiring a SSL connection would go a long way to prevent such eavesdropping.
Do you have an effective means of authenticating your users to establish their identity? If I can impersonate some other users I can probably read or overwrite all of their data. This is often handled through some form of user session created when a user correctly answers a security challenge. For example a user might enter their password or provide an oauth token from a third party like Facebook and then be given a cookie or session token to identify them for some period of time. An effective scheme will not allow an attacker to easily guess these session identifiers or steal them for the attacker's use (see point 1 above).
Once authenticated do you enforce authorization rules limiting what data a user may access? Even if you know (or at least believe) that I am a legitimate user of your API you should not trust me to only attempt to access my own data. I have seen a number of public APIs, particularly for mobile apps, fail on this step. In many cases it is trivial for me to follow a perfectly legitimate authentication process using your own app. Once I have done so I am free to use that legitimate user account and your own app's authentication process to craft whatever requests I desire against your API. You must not blindly trust clients of your API to be well behaved.
A common objection I hear to that last point is "but we wrote the only client app". Unfortunately writing the client does not mean you control it. As soon as that app is in your users' hands its behavior is no longer a secret. Your clever encryption scheme will be extracted, reimplemented, and used to make arbitrary API requests from curl. If that proves difficult it will be reused in place as an attacker calls your sendEncryptedAPIRequest method with their own parameters. Rather than attempt to keep your client's behavior secret while still making it available to your users it is better to enforce access controls as part of the API.
Where possible do you verify the integrity of the data you receive from a client? Even if I can only access my own data are you trusting me to provide reasonable values and what are the consequences if I do not? For an example look at almost any iOS app with an online leaderboard or high score list. If you trust a client to report their own score incredibly some of them will report very high scores indeed. Depending on what your app does and if any data is shared this may be more or less of an issue.
This does not leave you with a simple "do this and your API will be secure" answer but I'm afraid that is the reality of the situation. Security needs to be an ongoing consideration at every level of the software you build. Fortunately your requirements are unlikely to be unique so libraries and common practices exist to help with all of the areas described above.