Back 
We at Netskope Threat Labs have published a series of blogs detailing the misconfigurations in cloud apps causing data exposure. Misconfiguration and sensitive data exposure have been listed as predominant top 10 OWASP security risks for years, and are now also the predominant cause of cloud data breaches.
Our earlier posts detailed the exposure risk of popular apps, such as Google Calendar, Google Groups, other Google services, Zendesk, Office 365, Google Photos, Google Hangouts, and Discord. This blog post will demystify the types of exposure and the factors causing exposure. We will provide a checklist of specific features to look for when deciding whether to use an app to store, share, or otherwise process sensitive data. This approach can help organizations to evaluate a cloud app first and then deploy the app with the best practices and tight security controls, rooted in the key principle: “Evaluate first, Deploy later.” And for apps that are already used for sensitive data, this blog provides a checklist of things to lock down within those apps.
Extent of data exposure
First, we will look at the extent to which an app enables a user to share data, whether it’s public or internal within an organization.
Public data exposure
Public data exposure refers to data exposed to the entire internet. One classical example is sharing data using cloud services from Google. In this screenshot, the user generates a shareable link that is publicly accessible.
Google also offers a “Publish to web” option to index the content in major search engines. This not only means that the data is publicly accessible, but it is also easily discoverable by outsiders and adversaries. Public data exposure is a problem in all of the apps we have covered, such as Google Calendar, Google Groups, Google link sharing, Zendesk, Office 365, Google Photos, Google Hangouts, and Discord.
Internal data exposure
Internal data exposure refers to the data shared within one’s organization. This exposure is related to the accidental sharing of confidential information throughout the entire organization when it is supposed to be confined to a specific person or function. Generally, the documents are shared with a link that allows anyone in the organization with the link to view the file. In Figure 2, salary information was accidentally shared with everyone in the organization via Google Drive.
These documents can be discovered using the search function in Google Drive by people other than the intended recipients. This opens the data up to insider threats or discovery and theft by a malicious actor who gains access to the app from anyone’s account. This has been exclusively covered in our leaky app series on Google link sharing.
Risk factors
The next important aspect is the risk factors that contribute to cloud app data exposures and misconfiguration. These are broadly classified into three categories:
- Design factor
- Default factor
- Human factor
Design factor
Design factor refers to exposure risk inherent in the design of an app. One classic example is our post on Leaky images which detailed accidental exposure in Google Hangouts. In Google Hangouts, alongside the chat conversations, users can share images. These shared images are assigned a public link by the application’s design.
This link is universally accessible even outside of the application without any authentication. To take it a step further, a malicious insider can share snapshots of private keys, passwords, and tokens in a chat conversation. Because these are public links, they can be downloaded by anyone at any time.
Default factor
Default factor refers to exposures that are caused by the default settings of an app. One example is the case of basic group permissions for a Google account detailed in Leaky Groups. The default “Group visibility” and “Join the Group” permissions allow anyone on the web to see that the group exists and ask to join. As the group is visible to anyone on the web, the threat actor can leverage this in multiple ways, such as DDoSing the group with multiple requests and requesting group access by impersonating members of the group.
