Security guidelines

All University-published apps must observe these guidelines for security practices. Independent developers should consider them as a guide to sound practice. Security need not be a burden if you plan your app around it; back-filling, on the other hand, is painful.

What follows is a summary of the industry-standard OWASP Mobile Application Coding Guidelines. These are guidelines for discussing security, not rules; for a given app, more may be necessary, or less.

Identify and protect sensitive data on the mobile device. Information that must by law be secured against disclosure and abuse includes patient health records, student records, Social Security numbers, and financial account numbers, but this is not an exhaustive list, and you may want to be more careful than the legal minimum. IT Services will help you identify the data that needs protection.

Handle password credentials securely on the device. Do not persist passwords in a device’s file system or its user-preference system. If your platform provides a secured keychain for passwords, use it. Consider whether you need to keep a permanent record of passwords at all.

Ensure sensitive data is protected in transit. Use secured versions of network protocols — HTTPS and not HTTP, for instance — if the connection is to carry sensitive information. If you must encrypt data for transport, rely on the cryptography libraries provided by your platform, rather than trying to devise your own.

Implement user authentication and authorization and session management correctly. Your platform’s standard protocol clients will correctly interpret requests for credentials, collect them from your app, and forward them as the protocol demands. The platform libraries retain those credentials only as required for session management, and the app need not retain them. If you must write your own protocol handler, aim for that standard.

Keep the back-end APIs (services) and the platform (server) secure. If you communicate with a server, it must be at least as careful with the data it stores and transmits as these guidelines expect of your app. If your app is not secure as a system, it is not secure.

Secure data integration with third party services and applications. Avoid communication with apps and servers you do not control, unless you can be sure that your app is as secure with those services as without them. Do not communicate unless you can verify what you are communicating with.

Pay specific attention to the collection and storage of consent for the collection and use of user’s data. Your app should require the user to provide only the minimum information necessary for the app to deliver full value. If the user provides less than that much, provide reduced functionality if you can. If you want to collect more user data than the app’s value requires (such as demographics, or analytics of the user’s private, on-device usage), your app must make clear that collection is optional, and it must offer clear ways to bypass or opt out. Whatever you collect, treat it as confidential, and secure it accordingly.

Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls, etc…). Your app should not autonomously dial, send emails, renew subscriptions, send texts, etc., unless the content of each such transmission is fully disclosed, and the user explicitly authorizes it each time.

Ensure secure distribution/provisioning of mobile applications.

• If your platform has a curated “app store” that vouches for the authenticity, security, and safety of the apps it distributes, use it.
• If your platform permits distribution of apps through web sites, do so only through University sites carrying TLS authentication.
• If your app is to be distributed in-house only, download must be protected by CNet credentials. IT Services operates a server for this purpose.

Your app should never require a jailbreak to install or function.

Carefully check any runtime interpretation of code for errors. It is not always practical to capture error conditions at every point at which they might be reported, but you must not allow your app to cross critical boundaries without verifying the integrity of its data.

• Assume any data from an external source — the network or the user — is hostile until proven otherwise.Assume any data from an external source — the network or the user — is hostile until proven otherwise.
• You must check the integrity of data before it is stored, rendered, or transmitted. Depending on circumstances, incomplete or invalid data must cancel the task that is to handle it, or be replaced by safe defaults.
• Make early and frequent use of code analyzers and other tools to identify code that cannot be guaranteed to behave safely or predictably; the most insidious exploits take advantage of surprisingly-trivial lapses in things like word width or sign extension.