The Documents directory is intended to store non-transient application data, such as user-created content or local information allowing the app to run in offline mode. If UIFileSharingEnabled is set in your application's Info.plist file, files here will be accessible via iTunes. When writing sensitive data to the Documents directory, the data may be exposed in unencrypted backups or through the iTunes interface.

Example 1: The following snippet of code writes the user password in clear text within the Documents directory:

    ...
    NSString *docsDirectory = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    NSString *passwd_path = [docsDirectory stringByAppendingPathComponent:@"passwords.txt"];

    NSString *password = [user password];
    [password writeToFile:passwd_path atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ...

Some APIs that gather sensitive information can mishandle it by echoing it back to the user.

Example 1: The following code demonstrates the instantiation of a password callback object that does not obscure a user's password as they type it at the input prompt:

PasswordCallback pc = new PasswordCallback("Please enter your password: ", true);

Because pc in Example 1 was instantiated with its second parameter, onEcho, set to true, the password is not obscured when the user types it at the "Please enter your password: " prompt.

Always treat the social security number (SSN) as private information. This information is susceptible to theft if it is transmitted, stored, or processed in an unsafe manner. Access to legitimate social security numbers can lead to identity theft.

Privacy violation occurs when:
1. A social security number enters the program.

2. The social security number is written to an external location, such as the console, file system or network.

Transmitting social security numbers over an unencrypted channel, hardcoding them inside the application code, unencrypted storage of social security details in insufficiently protected back up files are some of the potential causes that could allow an attacker to gain access to a victim's SSN.

The SSN information could either be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging practice could also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk.

Collection and management of private information is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Privacy violations occur when:

1. Private user information enters the program.
2. The data is written to an external location, such as the console, file system, or network.

Example 1: The following vulnerable code contains a configuration statement that allows the secret "admin_password" to be logged unobfuscated .

from oslo_config import cfg
 ...
opts = [
  cfg.StrOpt('admin_password',secret=False,
               help="User's password")]
 ...              
grp = cfg.OptGroup('mygroup')
cfg.CONF.register_opts(opts, group=grp)
 ...
logger.warning("Adding %s" % cfg.CONF.mygroup.admin_password)

The code in Example 1 writes admin_password in plain text (unobfuscated) to the log output, as the value of secret is set to False. Although many developers trust the eventlog as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Attackers may exploit vulnerabilities in unchecked permissions in the following way:

1. Data enters the application from an untrusted source.

2. The data is used to represent the user or group identifier, list of permissions, or the resource to which the permission is applied, without undergoing any prior sanity checks. The application then uses this non-sanitized data to edit permission settings.

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to physical activity information can pose a danger to user privacy and personal safety. Applications that require access to user physical activity information must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the ACTIVITY_RECOGNITION permission, which enables an application to recognize the user's physical activity.

 <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the user's calendar can pose a danger to user privacy and personal safety. Applications must treat calendar data as sensitive and manage it with the utmost caution to maintain privacy.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CALENDAR permission, which enables an application to read the user's calendar data.

 <uses-permission android:name="android.permission.READ_CALENDAR"/> 

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CALENDAR permission, which enables an application to write to the user's calendar data.

 <uses-permission android:name="android.permission.WRITE_CALENDAR"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the call log can pose a danger to user privacy and personal safety. Applications that require access to the call log must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CALL_LOG permission, which enables an application to read the user's call log.

 <uses-permission android:name="android.permission.READ_CALL_LOG"/> 

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CALL_LOG permission, which enables an application to write to the user's call log.

 <uses-permission android:name="android.permission.WRITE_CALL_LOG"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the camera can pose a danger to user privacy and personal safety. Applications that require camera access must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the CAMERA permission, which enables an application to access the device's camera.

 <uses-permission android:name="android.permission.CAMERA"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to contacts information can pose a danger to user privacy and personal safety. Applications must treat contacts data as sensitive and manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CONTACTS permission, which enables an application to read the user's contacts data.

 <uses-permission android:name="android.permission.READ_CONTACTS"/> 

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CONTACTS permission, which enables an application to write to the user's contacts data.

 <uses-permission android:name="android.permission.WRITE_CONTACTS"/> 

Example 3: The <uses-permission .../> element of AndroidManifest.xml declares usage of the GET_ACCOUNTS permission, which enables an application to access the user's email and online accounts stored in the Account Manager. Sensitive data such as account IDs, email addresses, and phone numbers can be accessed with this permission.

 <uses-permission android:name="android.permission.GET_ACCOUNTS"/> 

Files written to external storage are readable and writeable by arbitrary programs and users. Programs must never write sensitive information, for instance personally identifiable information, to external storage. When you connect the Android device via USB to a PC or other device it enables USB mass storage mode. Any file written to external storage can be read and modified in this mode. In addition, files in external storage will remain there even after the application that wrote them is uninstalled, further increasing the risk that any sensitive information stored in them will be compromised.

Example 1:The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_EXTERNAL_STORAGE permission, which enables an application to write to external storage.

 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

Example 2:The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_EXTERNAL_STORAGE permission, which enables and application to read from external storage.

 <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> 

There is no good reason to request or grant a permission that disables the device.

Example 1: A program must not call this permission. Ever.

 <uses-permission android:name="android.permission.BRICK"/> 

Access to GPS location information can compromise a user's privacy and personal safety. Programs that access GPS location information must be careful to manage it with the utmost caution.

Example 1: The following code requests to receive updates to the changes of the location of the phone.

lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, locationListener);

SMS operations must not be performed without cause or consideration. Malicious software exploits these APIs to steal money and data from unwary users.

Example 1: In this case, the program sends a text based SMS.

sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the device microphone can pose a danger to user privacy and personal safety. Applications that require access to the microphone must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the RECORD_AUDIO permission, which enables an application to record audio using the device's microphone.

 <uses-permission android:name="android.permission.RECORD_AUDIO"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, Bluetooth access to nearby devices poses a danger to user privacy and personal safety as malicious actors can use Bluetooth functionality to monitor the device location or exploit vulnerabilities to eavesdrop and collect data. Applications that require Bluetooth access to nearby devices must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the BLUETOOTH_ADVERTISE permission, which enables an application to advertise to nearby Bluetooth devices.

 <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to notifications can pose a danger to user privacy and personal safety if sensitive information is included in sent notifications. Applications that require access to send notifications must manage it with the utmost caution and take precautions to prevent sensitive data leakage in notification messages.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the POST_NOTIFICATIONS permission, which enables an application to send notifications to the device user.

 <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to audio files can pose a danger to user privacy and personal safety. Applications that require access to audio files must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_MEDIA_AUDIO permission, which enables an application to read music and audio files on the device.

 <uses-permission android:name="android.permission.READ_MEDIA_AUDIO"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to photo and video files can pose a danger to user privacy and personal safety. Applications that require access to photos and videos must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_MEDIA_VIDEO permission, which enables an application to read video files on the device.

 <uses-permission android:name="android.permission.READ_MEDIA_VIDEO"/> 

Audio recording operations must not be performed without cause or consideration. Malicious software exploits these APIs to steal money and data from unwary users.