I couldn’t find a single place that covers the mobile developer security (must know) basics, this will be again like a chat between two developers (Lulu 👩🏼‍💻) and (Sam 🦖)

👩🏼‍💻: What are the risks of not having good security precautions? I can see we spend big money on security.
🦖: There are over 500 reported incidents of data-breach each year, It’s estimated that each incident costs 3.5M~5.0M USD on average.
If you look at statistics, you can see that remote jobs increased these costs by 15%, since attackers would have more opportunities of attacking a target that is spread on different locations.

👩🏼‍💻: When people talk about security, the server is being presented as the bottleneck, why would a mobile developer be concerned with security if the website is secure?
🦖: The weakest link is the bottleneck, if the client is poorly written, you should expect a lot of attacks on the server, also, users spend about 90% of their time on mobile rather than web browsers.

👩🏼‍💻: But you are an iOS developer, and I develop for Android, would your tips and hints be applicable to Android too? oh, I almost forgot that both are based on Linux.
🦖: wait, they are not both based on Linux, iOS is a Unix-like Operating System which is based on Darwin(BSD) operating system, while Android is Linux-based Operating System and is an open source mobile operating system, there are a lot of precautions that are applicable on both OSs.

👩🏼‍💻: I was asking myself in the past, why not rely on HTTPS and that’s it?
🦖: HTTPS protects users from other users, it doesn’t protect the server or the application sensitive data itself.

👩🏼‍💻: What are the mobile weak points? what can be hacked?
🦖: Network , Disk, USB Port, etc…

👩🏼‍💻: That looks like a lot of terminology, can you explain the basics?
🦖: You will be good to go if you know these as a start.

👩🏼‍💻: Why would people with a jailbroken device be a threat on the app itself, a jailbreak only make the user hackable, right?
🦖: No, The best practice, is to prevent people with Jailbroken devices from running your app, see my x04_checker repo, iOS Developers can use it to prevent jailbroken devices from running their applications.

Jailbreaking is the process of exploiting the flaws of a locked-down electronic device to install software other than what the manufacturer has made available for that device. It allows the owner to gain full access to the root of the operating system and access all the features, you must know that 100% jailbreak detection is not possible, we need to make (bypassing jailbreak detection) time-consuming, because an attacker can steal the developer info, and thus steal the app info.

👩🏼‍💻: They say debugging and print statements can be a security vulnerability, is this true?
🦖: Print normally only works on development builds, print will still send the data to the usb interface.

As you mentioned print, It’s a heavy command though, even if your debugging device is not connected in debug mode with Xcode, leaving print statement of heavy objects might make your app slower during development, but anyway, this is not our topic.

Keep in mind, NSLog will be left even in Distribution builds, any normal user can see the logs using the macOS console app, I used them when debugging opening the app using a notification when it’s terminated, this is not easy to do in Xcode directly, anyway, just use NSLog carefully, and treat the error log files with care, don’t log sensitive data, or leave trace of code symbols.

👩🏼‍💻: What about certificate pinning?
🦖: Certificate pinning simply prevents people from having the victim installing an incorrect certificate and making altered requests, you simply make the certificate a static asset in the binary, so an attacker can not have the victim installing another fake certificate to have them impersonated.

👩🏼‍💻: What about sensitive static strings?
🦖: Never have your sensitive strings inside plist or any asset file, this is the most basic tip you should never miss.
👩🏼‍💻: Wait Sam, I downloaded a facebook apk online, and ran a simple command to scan the binary for strings that look similar to google api keys, that begin with AIz, and I can see this, any explanation why this is not hidden in the binary?

 strings targetFile | grep "targetString"

🦖: There are multiple ways google makes sure that a request is authentic, from comparing hashes, to domain binding to bundle ids etc… again, you need to have your sensitive data hidden, this is not an excuse.

👩🏼‍💻: Why is it said to be risky to use 3rd party libraries when developing sensitive apps like banks?
👨🏻‍💻: In normal cases, libraries are fine, just make sure that they are being audited, NPM libraries had a lot of these, for sensitive apps, it’s better to avoid them altogether.

👩🏼‍💻: If I follow all of these tips, I will be completely secure?
🦖: The sad news is, No, there are a lot of other attacks, like URL-scheme attacks, when you define a url scheme, your app responds to that scheme, so for instance, you create a scheme myapp://. all links starting with your scheme will directly launch your app. A universal link doesn’t include your scheme in the url but they will still launch your application, apple allows other apps to the register the same url.
👩🏼‍💻: the alternative is universal links?
🦖: correct!

👩🏼‍💻: That was a huge amount of info for a starter, any final thoughts?
🦖: 100% Security for any Application is not possible but we can try to make the attacking/cracking of iOS App as much harder as possible.

Security is not always about “make accessing the data impossible”. sometimes it is about cost and likelihood of retrieval versus importance of the data.

More tips on top of my head:

• Avoid Objective-C if possible, it’s very easy to reverse engineer.
• Don’t write sensitive data into logs.
• Disable Keyboard caching (3rd party keyboard)
• Password/Pin should not be exposed during user interaction – Don’t include sensitive data in backup.
• User Credentials should be stored in (keystore, keychain…).
• SSL Pinning.
• App Transport Security – Certificate Pinning.
• Integrity Check.
• Prevent Running on rooted devices.
• Detect JailBreak, (Jail Monkey library).
• Use WebView carefully.
• Securing Data on disk.
• Securing Data across a network connection.
• Secure application logic.
• prevent Reverse Engineering (even if there is no sensitive data, if your app is novel, you don’t want people to see the code)
• Don’t share sensitive data with 3rd party
• Avoid keywords like (“jail”,”security”,”cydia”,”apt”) in variable & function names
• Hide the JB check deep in the app, not in appdelegate…
• Some Jailbreaks are permanent, and are done by exploiting security flaws in hardware.