Mobile computing is the new frontier of the online world, and Web developers are creating mobile-enabled Web applications that explore this frontier in new and exciting ways.  2010 showed that 3 percent of all Internet browsing activity occurred on mobile browsers, up from 1 percent at the end of 2009. 

As people put more faith in mobile devices, the impact of security breaches can be all the more devastating.  From the perspective of a mobile Web application developer, mobile devices can be an additional entry point into an application.  Creating mobile-friendly Web applications with security as a top priority is in the best interest of both mobile app developers and end users.

Securing mobile and non-mobile Web applications can be approached similarly.  It is the responsibility of the Web application to ensure that users of the application are protected from abuses.  Here are some considerations:

Protect Mobile Apps Against Physical Security Breaches

Unlike a desktop computer protected inside a house or a server locked inside of a secure building, mobile phones typically only have our pockets as protection.  Many people carry their mobile devices with them everywhere, which increases the chances that their devices will be lost or stolen.  The information on a lost or stolen device is at serious risk.  Many people don’t password protect their mobile devices, but even a password may not be enough.  A recent article published by the Huffington Post illustrates how simple it is for a malicious person to gain access to personal information on an iPhone, even when it is password protected. 

While there isn’t too much that a Web application developer can do about preventing lost or stolen mobile devices, they can design their application to limit the impact of such an event.  Web application developers should program with the "principle of least privilege" in mind, which states that nothing should have more privileges than is specified by its design.  For example, users of a Web application should not have access to see any sort of detailed error messages, logs, or other areas of the site that should only be accessible to an administrator. The idea is that one compromised account should not put the entire site at risk. 

Create an Audit Trail

Proper logging is vital for tracking activity on a Web application.  Logging helps administrators identify suspicious activity and recover from breaches or site failures.  It is important for tracking “significant events” on the site, such as transactions or message postings. 

Additionally, login pages should have audit logs that record attempted logins, the supplied username, the login time, the client’s IP address, and possibly the client’s geo-coded location.  A good example of how this information is useful is on Facebook and Gmail, where users are able to view the last several logins to their own account; this helps users and administrators identify suspicious activity within an account. 

However, when logging, it is important never to log personal or sensitive information such as user information or credit card numbers.  As an alternative, administrators may consider logging only an internal record ID, which by itself reveals no personal information.  Also, administrators should take care not to log excessive amounts of unnecessary information as it will tend to clutter the logs and hide the useful information.  Finding a good balance of what to log is key.

Employ Proper Encryption

If sensitive data is being exchanged between any Web application and an end user, HTTPS encryption should always be used.  The Web application administrator should purchase a valid SSL Certificate (for use with HTTPS) from a reputable Certificate Authority to further secure the connection, validate the website’s identity, and prevent certificate warnings from displaying in the end user’s Web browser.  Though many websites previously only employed encryption on login pages, the ever-present threat of information theft and the abundance of personal information now stored on the Web has led some companies to encrypt a user’s entire session.  For example, Google now offers options to encrypt searches, and now uses HTTPS to encrypt Gmail by default.  Facebook now includes account security settings which can encrypt a user’s entire authenticated session. 

HTTPS encryption is particularly important for mobile devices given that data is especially vulnerable as it is transmitted through the air.  Security researchers have demonstrated that cell phone data can be intercepted relatively easily using inexpensive equipment.  Mobile devices connecting through WiFi networks are even more vulnerable, as an attacker only requires a WiFi-equipped laptop to carry out an attack.  Encryption is a must for securing sensitive data.

Limit Data Stored on your Mobile Client

Personal data should never be stored on the end user’s device.  Since HTTP cookies and Flash cookies allow Web applications to store information within an end user’s Web browser, Web developers should take special care not to use these mechanisms to store sensitive information.  Not only are HTTP cookies sent across the network in every request to the Web application, but many Web browsers store this cookie information in clear text files on the client device. 

Instead of storing sensitive data in cookies on a client, a better approach is to store randomly generated session keys in a cookie on the end user’s system.  The session key can then be used to look up user information from the website; no sensitive data is stored on the user’s device.  Minimally, all Web applications needing to track user state or logins should be using a strategy similar to this.

Almost all modern mobile devices support the new HTML5 specification.  While HTML5 client-side storage offers Web developers many new opportunities to create innovative Web services, it also introduces a new means for abuse.  HTML5 brings the ability to store large amounts of data on an end user’s device in client-side persistent storage.   Depending on how the Web application decides to store data on the end user’s device, entire documents or programs could be persistently stored in this client-side storage.  This exposes a risk to the end user and a Web application if an end user’s device is compromised. 

When designing Web applications, developers should be mindful of what information they are storing on the client device and the potential abuses. 

Sanitize Input

In addition, a Web application needs to carefully sanitize any data provided back to it, whether that data be from the end user device’s client-side storage, from a submitted html form, or from an HTTP or Flash cookie.  A Web application should never fully "trust" data that is sent to it from a client and should take all means available to validate that the data received is the data expected. Any input driving database activity should be thoroughly sanitized and any user-submitted data stored in a database should be properly escaped if it is rendered on a Web page (to prevent scripting attacks).  

Few have felt the impact of improper input validation on their website more than HBGary, a security firm which was recently compromised through a SQL injection attack.  This failure to properly sanitize input to their Web application contributed to thousands of private emails being leaked, their public website being vandalized and the resignation of their CEO.  Clearly, improper input validation can have disastrous results.

Mobile Web App. Development: Final Thoughts

With the unprecidented rise of the mobile Web, companies and vendors alike are scrambling to establish themselves in this exciting space.  But proper security measures are easy to gloss over because they happen in the background.  Often times, a breach is the first indication of poor security practices.

Protecting your mobile site against compromised accounts, logging significant activity, encrypting data, limiting data stored on the mobile device, and sanitizing inputs received from the mobile device are just a few of the ways to protect Mobile Web applications and users from information theft and malicious activity.  With the proper foresight and the proper development partner, this new mobile frontier does not have to be a Wild West.