Companies of all sizes feel the need to have a mobile app to be taken seriously. But the rush to mobile has also...
exposed companies to privacy-invasion and security problems, generating customer anger and angst from an application intended to be a customer perk. These mobile app security problems are more daunting -- and potentially more damaging -- for small businesses, where budgets are small and IT support is minimal, if it exists at all.
Our advice? Put your bigger brethren to work by learning how to avoid the mobile app security mistakes they've made. (By the way, your very first decision is whether your organization really needs a dedicated mobile app at all. See sidebar, "Could a simpler, cheaper and safer 'shell' serve your needs?")
Open-ended questions invite a privacy breach
Delivering a personalized experience has long been the hallmark of a successful small business -- a place where personnel know their customers and how they like to be treated. It's only natural that the friendly neighborhood dry cleaner, diner, fashion boutique or car wash would want its mobile app to do the same. But beware: Any personal data collected from a mobile app could turn up in unintended and awkward places. And you will get blamed, even if the customer is at fault for the privacy invasion.
Mobile app vs. 'shell'
Do you need to create a true mobile app versus a shell? A shell looks like an app, launches like an app, is downloaded from the official app stores like an app, but its functionality after launch is identical to what would happen if the customer simply launched his mobile device's Web browser and typed in your URL. In other words, a shell looks like any other app on a mobile device but simply acts as a button used to launch a company’s website.
Is this right for you? It depends on your business and what you want the app to do. The shell is less expensive and easier to develop, so if dollars and time are tight, it's worth considering. The key question: Do you plan to use any of the powerful capabilities of the mobile device, such as geolocation, video/photography, microphone activation or the accelerometer? (Pizza Hut’s first app, for example, used the accelerometer as a way of indicating where toppings should be placed. When a customer wanted to indicate that she wanted a topping on only half of the pizza, she angled the phone and watched the topping slide all to one side.) Those capabilities might be beyond the needs of small businesses looking for a secure app at a lower cost. In that case, a shell is a good alternative.
A large medical company found this out the hard way. The women's health app it commissioned offered what probably seemed like a useful feature for a certain female demographic. The mobile app gave women an open-ended field where they could enter notes about their medical situation, such as their menstrual cycles and any encounters that might have impacted said cycles.
The health notes were supposed to be seen only by the woman who wrote them. But the app included advertisements, and as the ad network grabbed click through data, it also grabbed everything else -- including the mobile device ID and other information that specifically tied the information to an identifiable person. Into the ad servers those highly-personal notes went, where they were carried into umpteen backups and into countless spreadsheets and analytics programs, according to Daniel Miessler, who oversees mobile app testing procedures at Hewlett-Packard Co.'s Fortify unit, which helped fix the data leak.
Recommendation #1: Avoid open-ended options where customers enter whatever they want. Determine what information your business really needs while protecting customers or prospects. Developers and marketers are often quick to throw in questions and features, not thinking about how bad it would be if such collected data gets out.
A picture can be worth many mobile security problems
Just about every smartphone today can take high-quality photographs and videos. Why not leverage those visual features in your mobile app and encourage shoppers to use those visual captures?
Certainly, for some businesses, digital images are key to an app's functionality: Consider a camera store app that helps customers fix bad photos by leveraging the complicated settings associated with high-end cameras. Or think about an auto-insurance company that lets insured customers photograph car damage at the time of an accident.
But if photographs and videos don't add much strategic value, businesses set themselves up for security risks. What kind of damage could a digital picture pose? Unless the customer initiates elaborate steps to block it, digital photos today are married to metadata, which can intrude on a person's privacy by indicating the exact location, time and date of the photo. Take enough photos over time and the metadata provides a detailed roadmap of that customer's travels.
It's not just the metadata but the photograph itself that can reveal details your business might not want public. A photograph intended to show an antique dining room table, for example, can also accidentally capture details of a bill that was on the table at the time.
The same privacy concerns about photographs also apply to geolocation tracking, as Starbucks learned the hard way.
Recommendation #2: If you have a critical business need to use photos or videos in your mobile app, do so. But if it's just a fun, added feature, consider all of the ways a photo could come back to haunt you.
Let your app server be an island unto itself
Here's a frightening but not unheard of scenario for a small business' mobile app: Its code is downloaded to a very powerful computer that is fully controlled by a potential cyberthief or by a direct business rival seeking to steal your customers and damage your brand. They manipulate the code and do anything they can to sabotage your business.
How can such a thing happen? By being server-cheap and security foolish. The cheapest route to manage a mobile application is to let the app interact with the business' primary server, the one that handles payroll, processes customer payment card transactions, houses your customer lists as well as contact information for suppliers, including internal price lists. Alan Heyman, managing director of the SMLR Group, a cybersecurity consulting firm, gave this advice: "Make sure that the mobile app information is on a distinct server not connected to any other part of your business."
Recommendation #3: Spring for a dedicated server to interact with your mobile app. (It can be very small.) For some small businesses, this might be an opportunity to explore a low-end cloud server, where maintenance is someone else's headache. You want a machine that has zero access to any of your other systems. If you make sure the mobile app server has security on it, but with full isolation, you have put a fairly low ceiling on those worst-case scenarios.
Go to part two of Schuman's piece, "Automated scripts can cause mobile app security problems" for Recommendations #4, #5 and #6.