The top 10 travel apps in the iOS and Android app stores are all riddled with security flaws, according to a new report from Bluebox Security.
The biggest problems include a lack of encryption for app data, insufficient protection against main-in-the-middle attacks, and leftover administration or debugging code.
The company looked at the leading travel apps based on data from App Annie, a mobile applications analytics company, picking 10 apps that were available on both the iOS and Android platforms.
The biggest problem was a lack of encryption for data at rest, said Andrew Blaich, lead security analyst at Bluebox Security.
Although smartphones may have full-disk encryption built in, this doesn't protect data while the phone or tablet is being used.
"It only works when the device is off," said Blaich. "But while the device is running, the data can be stolen by other malicious apps -- or by someone grabbing the device from your hand."
Only one of the 10 Android apps, and none of the 10 iOS apps encrypted data, he said.
"And the one app on the Android side that did some sort of encryption, embedded the keys to the encryption in the source code, so you could go ahead and decrypt the data anyway," he said.
In addition, while all the apps used encrypted HTTPS to communicate with their central servers, only two of the 10 Android apps and one of the 10 iOS apps used certificate pinning to check that they were, in fact, talking to whom they were supposed to be talking to.
"If you man-in-the-middle that connection then you can see all the information that is being passed along the network in plain text," he said.
Another problem is that developers sometimes add debugging or administration functionality to their applications during the coding process -- and forget to take it out again when they release the app.
This functionality could give special privileges to the user, or, for example, allow them to skip the payment step while making a new reservation.
Four of the 10 Android apps and six of the 10 iOS apps had this problem -- and none of these apps had anti-tampering measures.
"It's there for convenience of developers," Blaich said. "They don't think that this behavior can be switched on by users once it's shipped out, but they had no protections against turning it on."
Attackers could activate this restricted functionality and take full control of the apps either to profit from abusing them directly, or to launch attacks on other apps.
Finally, Blaich said, many app developers used third-party libraries. On average, 70 percent of the code of these apps were third-party components.
Sign up for Computerworld eNewsletters.