Store sensitive information in Keychain
Set Data Protection to
NSFileProtectionComplete wherever possible.
Do not store sensitive data you don't actually need, or for longer than you need.
Store application-specific authentication tokens rather than passwords.
Use HTTPS to verify the server you are contacting. Never accept an invalid or untrusted certificate.
When connecting to your own server, validate that the service presents a certificate that youhave signed, not just "a trusted certificate."
This is just a smattering of approaches, but they set the basic tone:
Use the built-in APIs to store things. As Apple improves security, you get the benefits for free.
Avoid storing sensitive information at all and minimize the sensitivity of what you do store.
Verify the services you communicate with.
It may not be possible to stop the piracy but we can make it tough.
Prevent the app from running on Jailbroken devices (think twice, you may lose valid customers)
Add code that detects the existence of Jailbreak
Prevent the app from attaching to debuggers
Apps downloaded from AppStore are encrypted. Debuggers are used to decrypt and analyze the App. Add code that detects debuggers.
ATS should be configured according to best practices by Apple and only be deactivated under certain circumstances.
If the application connects to a defined number of domains that the application owner controls, then configure the servers to support the ATS requirements and opt-in for the ATS requirements within the app. In the following example,
example.com is owned by the application owner and ATS is enabled for that domain.
If connections to 3rd party domains are made (that are not under control of the app owner) it should be evaluated what ATS settings are not supported by the 3rd party domain and if they can be deactivated.
If the application opens third party web sites in web views, then from iOS 10 onwards
NSAllowsArbitraryLoadsInWebContent can be used to disable ATS restrictions for the content loaded in web views
More about ATS
NSAllowArbitraryLoads key is set to
NO by default. Setting the key to
YES will opt-out of ATS and its associated security benefits. If in testing an app you find this key set to
YES, verify why the developers decided to opt out. In addition, check into the
NSExceptionDomains exception and whether any domains are listed there. We’ve encountered a number of cases where developers have opted out of ATS globally, but then opted in only for certain domains by listing an exception domain. A better approach is to enable ATS globally, and only opt out for certain domains if absolutely necessary (more on that in the NSExceptionDomains section below).
If they key is set to
YES, spend time verifying:
The ciphers used for the app’s backend connections (and that they’re strong)
The protocols used to send and retrieve data (and that they’re secure)
Whether the app has any downgrade vulnerabilities
Whether the app validates certificates used for TLS connections
While you should perform testing in these areas regardless of the ATS configuration, a developer setting this key to
YES increases risks in these areas.