HTTP requests which utilize the GET method allow the URL and request parameters to be cached in the browser's URL cache, intermediary proxies, and server logs. This could expose sensitive information to individuals who do not have appropriate rights to the data.
Example 1: The following code makes an HTTP request using the GET HTTP method instead of POST.

...
	NSString * const USER_URL = @"https://www.somesvr.com/someapp/user";
...
	NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
	[request setHTTPMethod:@"GET"];
...

Example 2: If the application uses NSURLRequest then the default HTTP method is GET.

...
	NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.apple.com/"]
                        cachePolicy:NSURLRequestUseProtocolCachePolicy
                    timeoutInterval:60.0];
	NSURLConnection *theConnection=[[NSURLConnection alloc] initWithRequest:theRequest delegate:self];
	if (theConnection) {
    	// Create the NSMutableData to hold the received data.
    	// receivedData is an instance variable declared elsewhere.
    		receivedData = [[NSMutableData data] retain];
	} else {
...

When creating an instance of NSURLCredential containing the user's credentials in the form or a username/password pair or a client certificate, a persistence attribute needs to be defined. The possible values are:

- NSURLCredentialPersistenceNone: Credential should not be stored.
- NSURLCredentialPersistenceForSession: Credential should be stored only for this session.
- NSURLCredentialPersistencePermanent: Credential should be stored in the Keychain.
- NSURLCredentialPersistenceSynchronizable: Credential should be stored permanently in the Keychain, and in addition should be distributed to other devices based on the owning Apple ID.

The NSURLCredentialPersistenceSynchronizable attribute implies the distribution of the credential and its storage in the Apple's cloud environment. Depending upon the privacy requirements of the application, storing the credential in the Apple cloud environment may not be acceptable.

Example 1: The following snippet of code creates a synchronizable credential that will be distributed to other devices and iCloud:

    ...
    NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 
    ...

Privacy violations occur when sensitive data is persisted to disk in an unencrypted format.


Example 1: The following ASPX code instantiates a DataVisualization control that generates a graph of sensitive financial information from the XML Data Source SensitiveXMLData:

        <asp:Chart ID="Chart1" runat="server" ImageLocation="~/Temporary/Graph"
            ImageType="Jpeg" DataSourceID="SensitiveXMLData" ImageStorageMode="UseImageLocation">
            <series>
                .
                .
                .
            </series>
            <chartareas>
                <asp:ChartArea Name="ChartArea1">
                </asp:ChartArea>
            </chartareas>
        </asp:Chart>
  

The code in Example 1 instructs the Chart control to produce a JPEG image of the bar graph and write it to the temporary directory ~/Temporary/Graph. After the control writes the image to disk, the user's browser will make a subsequent request of the file and display it to the user. The image is not written securely to disk. Also, the code assumes that the underlying infrastructure will protect the file from unauthorized access by another user.

When creating an instance of NSURLCredential containing the user's credentials in the form or a username/password pair or a client certificate, a persistence attribute needs to be defined. The possible values are:

- NSURLCredentialPersistenceNone: Credential should not be stored.
- NSURLCredentialPersistenceForSession: Credential should be stored only for this session.
- NSURLCredentialPersistencePermanent: Credential should be stored in the Keychain.
- NSURLCredentialPersistenceSynchronizable: Credential should be stored permanently in the Keychain, and in addition should be distributed to other devices based on the owning AppleID.

Since NSURLCredentialPersistenceSynchronizable credentials are distributed to other devices and iCloud, failing to completely remove the credential from all places will leave instances that could be leaked.

Example 1: The following snippet of code creates a synchronizable credential, uses it and then removes it locally but fails to remove it from other devices and iCloud:

    ...
    // Create the credential
	NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 

    // Use the credential as needed
    ...

    // Removes the credential
    [shared removeCredential:credential forProtectionSpace:protectionSpace];
    ...

Users expect applications to provide meaningful and user-friendly messages when there is a failure. However, when a login failure occurs due to incorrect credentials, providing verbose errors/messages might provide an attacker with information on how the application authorizes users.
For example, consider an application that takes an email address and a password. If the application provides different error messages for a non-existent email address and an incorrect password, it enables an attacker to submit multiple email addresses and discover the email addresses that are registered to the application. Such brute force attacks can provide extra information that can enable an attacker to proceed further.

Privacy violations occur when private user information is stored in an unprotected location.
Example 1: The following XML contains a user's private information within a plist file. Among other values that are stored, the MyCreditCard key stores a user-supplied plain text credit card number associated with the account.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>password</key>
  <string>BASICSECRET</string>
  <key>credentials</key>
  <dict>
          <key>pin</key>
          <string>2345</string>
          <key>MyCreditCard</key>
          <string>1111 11 2321 1112</string>
          <key>MysSn</key>
          <string>1111-22-3333</string>
          <key>ssn</key>
          <string>2345-22-3345</string>
          <key>userid</key>
          <string>12345</string>
  </dict>
</dict>
</plist>

The code in Example 1 stores private user information from the mobile device in an unprotected plist file stored on the device. Although many developers trust plist files as a safe storage location for any and all data, it should not be trusted implicitly particularly when privacy is a concern, since plist files may be read by anyone in possession of the device.

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.

- Retrieved from mobile data stores including: Address book, snapped photos, geolocation, configuration files (including plist), archived SMS messages, etc.

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 student identification 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 additional 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, inside plists, or in other locally-controlled resources. However, even if access to certain resources is restricted it does not guarantee that individuals that have access should be trusted with that data. 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.

The identified field does not disable iOS' keyboard caching mechanism. As a result, any sensitive information recently entered into the field will be cached by iOS in an effort to improve its autocorrection feature.

Example 1: Input entered into a sensitive text field is stored in the system's keyboard cache:

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

The code in Example 1 indicates that the app utilizes an input control designed to collect sensitive information. As iOS caches input into text fields in order to improve the performance of its autocorrection feature, any information recently entered into such an input control may be cached within a keyboard cache file saved to the file system. Because the keyboard cache file is stored on the device, if the device is lost, it may be recovered, thereby revealing any sensitive information contained within.

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.

- Retrieved from mobile data stores including: Address book, snapped photos, geolocation, configuration files, archived SMS messages, etc.

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 student identification 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 additional 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, it does not guarantee that the individuals who do have access can be trusted with certain data. 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.

Disclosing national identifiers that uniquely identify an EU citizen constitutes a violation of an individual's privacy under the EU General Data Protection Regulation (GDPR).

The EU General Data Protection Regulation (GDPR) replaces the Data Protection Directive 95/46/EC, and is designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens' data privacy and to reshape the way organizations across the region approach data privacy. GDPR provides a framework for organizations on how to handle personal data.
According to GDPR Article 4 personal data "means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person."

The identified UIViewController subclass does not implement the appropriate methods used to hide screen elements before iOS caches the screen's contents. This will reveal any sensitive information that has been entered within input controls before an app is backgrounded.

Example 1: Input entered into iOS text controls may be stored in a screenshot taken when an app is backgrounded (i.e. the "Home" button is pressed while the app is active).

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

The code in Example 1 indicates that the app utilizes an input control designed to collect sensitive information. As iOS takes a screenshot of the active view of an app when it is backgrounded in order to improve animation performance, any information displayed in such input controls during the background event may be cached within an image saved to the file system. Because these screen cache screenshots are stored on the device, if the device is lost, they may be recovered, thereby revealing any sensitive information contained within.

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.

- Retrieved from mobile data stores including: address book, snapped photos, geolocation, configuration files, archived SMS messages, etc.

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 student identification 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 additional 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, it does not guarantee that the individuals who do have access can be trusted with certain data. 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.

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"/>