1

I am beginning to develop apps for Android and iOS that make API calls to a PHP web application that I will be developing. Users will be required to sign up with a username, password, and (optional) phone number and email, and I plan to keep this data in an SQL database. Users will be able to sign up from the phone apps as well as on the website where the PHP-based API is hosted. I know that all too often application developers do not prioritize security and I would like to make sure that I do.

In terms of web-server security what can I do to make sure that my users' data stays secure? When developing, what types of security practices should I put in place to keep my application as secure as possible? (e.g. sanitizing username/password input to prevent SQL injection, SSL for API calls from apps to the web server, not making API calls with plaintext passwords, etc.)

I know the question is broad but I think any answer represents the possibility of increased protection that I have not thought of.

  • 1
    @ztk I am not looking for a programming-type answer, I am looking for an answer from a security perspective so I figured the security Stack Exchange site would be best but I will move it if you still think I should. – jstrieb Jul 28 '15 at 20:01
  • 2
    @ztk This is definitely a security question, it's perfectly on-topic here, unfortunately you would need an entire textbook to do justice to the question, making it way too broad. Incidentally, I would suggest that the OP look into buying some good books on the subject. – Mike Ounsworth Jul 29 '15 at 16:13
  • @MikeOunsworth I figured it was a little broad but did not know where to start. Do you have any good book recommendations? – jstrieb Jul 29 '15 at 17:09
  • Check out these two questions on PHP / web sec book recommendations, question1, question2. – Mike Ounsworth Jul 29 '15 at 17:16
5

From the top of my head :

  • the API server's security, which means you may need to hire a competent sysadmin to take care of it if you aren't experienced with system administration. Whatever security you implement on top of that (API authentication, etc) becomes moot if your server itself is compromised. Keep in mind that every software installed on it is a liability and only install what you'll actually need, for example do not leave a PhpMyAdmin instance installed just in case you need it.
  • separate the server that hosts the API from the one that hosts your public-facing website, ideally your public website can be compromised without any risks for the app's data since it resides on a separate machine.
  • run away from shared hosting. It may be tempting to sign up for a shared hosting plan (they're so cheap and don't seem to require any maintenance) but their security is disastrous (even more if they're using this cPanel mess as the hosting server is most likely already compromised) and a code execution exploit on someone else's site can be leveraged to use a kernel exploit, get root access and compromise your API and data.
  • harden your web stack to not execute arbitrary PHP files - if you're using a framework (you should), the only file that should be executed is the framework's entry point (usually index.php), that way even if a rogue PHP file somehow finds its way onto your server, it won't be executed and you will still be somewhat safe (make sure to check how the file got there in the first place and whether any other code execution occurred). Read my somewhat-related answer from my old account.
  • of course make sure to handle user input correctly, hash passwords correctly and check out OWASP.
  • every piece of personal data you collect is a liability in case your server gets compromised (it's only a matter of when) - do you really need user's phone numbers ? (sending them SMS spam isn't a correct answer, and neither is 2FA authentication as it can be done completely offline using TOTP/HOTP without requiring phone numbers)
  • harden the server's TLS configuration - allow only the strongest ciphers supported by your target market, for example if you target iOS7 devices then allow only the strongest ciphers supported from iOS7 and upwards. If targeting iOS8 do the same but only allow the ones supported by iOS8, disregard any weaker ciphers as you don't care if older devices won't support them. Enforce forward secrecy if the ciphers you chose allow it. Use your own CA to sign your API server certificates and embed that CA cert into your app to prevent any other CA from posing as your server (remember DigiNotar?).
  • add some rate-limiting and strong captchas for repeated actions to thwart bruteforce and spammers.
  • avoid embedding third-party analytics code into your app - not only is that disrespectful to the user (the fact of opening your app shouldn't ping some third-party's analytics server, no matter how secure it is) but that can also hinder security as they may have vulnerabilities or lower security requirements (allowing weaker TLS ciphers, etc).
  • Thanks! You definitely present some ideas here that I had not thought of. Corrected the phone number thing, too--I meant to make that optional like the email, however I will need it because I need users to have the ability to "add" other users based on the phone numbers from their contacts (similarly to what is implemented by Snapchat). Also, I ended up at the PHP: The Right Way site from your old Security Stack Exchange post you linked to, and I think that will be a massively helpful resource as I am a relatively unseasoned developer. So thanks for that, too. – jstrieb Jul 28 '15 at 20:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.