Apple makes an all-out effort to make the App Store a “walled garden” and keep the owners of their mobile gadgets safe and sound… unless it doesn’t.
The garden is still filled with snakes, bugs and hungry malware. Despite all the built-in security features, hackers manage to penetrate approximately 40% of the most-used free iOS apps.
Hundreds of top-featured iOS apps were infected with malware via modified XСode over the last year alone.
The state of facts for every developer is, one can’t just rely on Apple data protection measures and call it a day. You need to implement protection right into your app functionality.
Find out how to make your iOS app as secure as Fort Knox without much effort by following these tips.
1. Sock away sensitive data!
The critical and yet most common mistake iOS developers make is failing to secure data storage and transferring. This inconsideration leads the OWASP Top 10 vulnerability list for mobile apps.
Due to weak protection, the hacker group AntiSec has hijacked and exposed the personal data of one million Apple customers. They claimed to obtain full names, addresses, and phone numbers of 10 million more owners of Apple’s iPhones and iPads.
When you’re developing an app, by the nature of the case you have to decide what data to keep on a device, and which to transmit back to the database. The best time to do so is before your team have started the magical process of turning coffee into code.
This is the rule of thumb for each mobile app developer to follow: Don’t store sensitive data locally if you can avoid it.
Yes, keeping user data directly on their iPhone or iPad is tempting. The more of it you store on the device, the faster your app performs. Hence the better user experience.
Well, you can’t have the best of both worlds. It wouldn’t be rocket science for a willing hacker to pull out any personal, financial, and legal information that your app stores locally. It doesn’t help that a lot of users don’t update their iOS timely. Currently near 20 million iPhones aren’t receiving security updates at all!
Also, if they happened to lose their device, or if it is stolen, all their private data is lost.
Hence, if security is your number one priority, keep sensitive data on the back-end DB server, under the shield of corporate security devices.
2. Don’t leave the key under the “welcome” mat
What if you absolutely need to store some sensitive data locally? In some cases it’s required for the app to work properly.
Then, for crying out loud, don’t keep it in plain text! Use Apple’s File Protection Mechanism, or any of the countless encrypting tools to safeguard user-grade data from attackers.
Make sure that all data exchange between your iOS app and its back-end web services is encrypted at every turn. Your app’s performance is only as secure and reliable as its weakest link.
To protect your iOS app from reverse-engineering you should include strong binary protection schemes.
Use SSL/TLS protocols to prevent “man-in-the-middle” attack. All the SSL certificates must be 2048 bit-keys based. Cracking the last generation certificate would take over 6,4 quadrillion years. For comparison, it’s “only” 13.8 billion years since the Big Bang. The Universe will come to an end before some cyber-villain will come anywhere close to cracking it!
After encrypting your client-server communication, make sure the key itself is well-protected. In other words, don’t hardcode your crypto key, and don’t store it locally on the device. A good practice is to create a key exchange system, and keep the keys on a remote secure server.
Supreme iOS app development service
3. Trust no user input
Did your parents tell you not to trust strangers, and not to take candies from them? I bet they did, probably more often than necessary.
Your application is your child, right? Then teach it to handle all user requests as untrusted. This is how you can secure identification and authorization:
- Make sure your app accepts only properly validated SSL certificates. You can achieve this by setting thesetAllowsAnyHTTPSCertificate
- Implement URL schemes for extra-validation. There is no such thing as too much precaution, especially if your app is for corporate usage.
In addition, you want to prevent injection-based attacks, and weed malicious SQL statements out of your app’s databases. This is where OS command injection, SQL injection, JSON/XML injection and similar techniques come in handy.
- Double-check what network resources your app can get access to. Then think about whether it’s justified.
Last year Apple faced a 5 million dollar lawsuit, and made iPhone 5 owners mad, over a new feature. Their Wi-Fi Assist was sneakily switching to cellular mode, supposedly to help them stay in-touch when Wi-Fi connection is poor, thus gulping down cellular data without permission.
- Finally, use reliable server-side authentication – cover your back end!
4. Handle sessions properly
What good is installing a monster-lock on the door if you leave it wide-open? And that’s what mobile apps are often guilty of. Quite often they are clumsy when it comes to handling sessions. In some cases, the sessions are left hanging open infinitely. It creates a loophole for attackers.
- Don’t let your app override session timeouts or reconnect automatically. Timeouts exist for a reason. And the reason isn’t to annoy users, as one might think, but to prevent infinitely open sessions.
- Make sure your app’s session identifiers are strong. They have to use the largest character set available and to be randomized.
- Be careful when implementing “Remember Me” Check if your app kills the session after the logged-in user has closed it and whether their login/password are stored safely.
5. Try to break into your own house
So, you went above and beyond to make your app hacker-proof by following the previous steps. Your product is rich, well-performing, full-featured, and ready to launch.
Hold on just a second.
Remember all these functional tests, performance tests, integration tests you had to run to make your product that clean and shiny? Now it’s time for one more kind – penetration testing. You can hire white-hat hackers for that, and let them try to break in. You’ll be surprised by how many missed loopholes and uncovered gaps they find.
According to statistics, the companies that never perform penetration testing have twice as much open vulnerabilities in their software, compared with those which run pen tests annually.
Of course, you could never guarantee a 100% unhackable application – let’s be realistic. Neither you can follow every single clueless user of your product and talk them out of clicking sketchy links and installing fishy software.
What you can do after a release is to keep caring about your customers by providing tech-support and security patches. Try to come as close as possible to ideal. It’s up to you!
Contact us for further guidance and support!