iOS specific SMS-related operations should not be performed unless they are essential to the core functionality of an application. Malware written for mobile devices often abuses such functionality to steal money or data from the user.

Example 1: In following cases, the application sends an SMS message or precomposes and presents an SMS message to the user that he or she is prompted to send or cancel:

...
Device.OpenUri("sms:+12345678910");
...

Access Control: Authorization Bypass issues occur when:

1. Data enters a program through an untrusted source.

2. The user-controlled data is passed as a parameter to a method which causes the method to skip authorization checks within.
Example 1: The following code supplies a user-controlled indicator to a method that fetches employee data:

    ...
	PARAMETERS: p_xfeld TYPE xfeld.
    ...
CALL FUNCTION 'BAPI_EMPLOYEE_GETDATA'
  EXPORTING
    employee_id      = emp_id
    authority_check  = p_xfeld
  IMPORTING
    return           = ret
  TABLES
    org_assignment   = org_data
    personal_data    = pers_data
    internal_control = con_data
    communication    = comm_data
    archivelink      = arlink. 
    ...

If an attacker supplies whitespace for parameter p_xfeld, no authorization checks are performed before returning an employee's personal and contact information.

Some functions may enable a programmer to specify an explicit value for whether permission was allowed. This can then be abused to violate what the user wants and still assume the permission was given.

Example 1: The following code asks permission to use the user's location on Android while using WebView, yet uses the user's location whether or not permission to do so is granted. This is achieved by manually invoking the callback with true to specify that permission was given:

public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions$Callback callback){
  super.onGeolocationPermissionsShowPrompt(origin, callback);
  callback.invoke(origin, true, false);
}

A ColdFusion application might inadvertently display detailed error messages to the user. These error messages might contain sensitive information that can enable an attacker to conduct more targeted or damaging attacks.

The OAuth protocol enables a user to leverage a third-party application (a consumer) to access their resources on a provider application without sharing credentials from the provider to the consumer. Instead of traditional authentication tokens such as a username and password pair, the consumer uses a token and a shared secret to identify itself to the provider. After the channel between the consumer and provider is established, the individual users are authorized through that channel using an access key token and a shared secret provisioned by the provider.
The transmission and storage of these tokens and secrets should be performed as carefully as other credentials are in traditional web applications. In the absence of Secure Sockets Layer (SSL) or Transport Layer Security (TLS), these tokens and secrets are sent in plain text over HTTP and can be seen by anyone eavesdropping on the traffic.

Server certificates declare the public key of the server for use in transport layer security. Trusted third-party vendors known as Certificate Authorities (CAs) sign and issue the certificates to ensure that they are authentic and contain the public key of the intended server. The public key of the root CA is embedded in the operating system (OS) by the vendor (e.g. Microsoft for Windows or Apple for macOS). After receipt of a certificate, the client (e.g. a web browser) verifies the identity with the OS's embedded trusted CA. In case of a self-signed certificate, the certificate is signed using its own private key, and the client is unable to verify the certificate owner identity with a trusted CA. Because third-party verification is not possible, attackers can mount a man-in-the-middle attack by issuing a certificate with fake details and a public key that they control.

Clients often display a security warning after encountering a self-signed certificate, although the user can usually override this behavior and manually trust the certificate. However, using self-signed certificates in production can encourage the insecure practice of overriding these certificate warnings without properly verifying the certificate's details, which in turn can make users more susceptible to man-in-the-middle attacks.

With a successful man-in-the-middle attack, an attacker can modify or steal sensitive data as it is transmitted. Because self-signed certificates are not verified by a third-party, it is difficult to revoke them. A security issue such as Heartbleed could require servers to revoke their certificates to ensure the effectiveness of bug remediation.

LDAP error messages can reveal details about the users and network hosts. The foremost defense that applications can use against malicious attacks is minimizing the application knowledge revealed to the attacker. Most prominent vulnerabilities occur as a result of unintended application behavior triggered by unexpected user input.

Attackers exploit this fact to force applications into disclosing details about their functionality. Error messages act as a primary source of this knowledge. Details revealed via LDAP error messages can enable an attacker to effectively craft LDAP injection payloads.

XPath error messages can reveal details about the structure of XPath queries used by an application to interact with XML documents. The foremost defense that applications can use against malicious attacks is minimizing the application knowledge revealed to the attacker. Most prominent vulnerabilities occur as a result of unintended application behavior triggered by unexpected user input.

Attackers exploit this fact to force applications into disclosing details about their functionality. Error messages act as a primary source of this knowledge. Details revealed via XPath error messages could allow an attacker to effectively craft XPath injection payloads.

Sensitive information persisted using HTML5 storage objects are stored on the client-side. While this option might seem attractive from a performance perspective, any information stored on the client is easily accessible and can pose a security risk if it is accessed by an unauthorized third party.
Storing sensitive information in the localStorage or sessionStorage objects provided by HTML5 is not a secure. While this information might not be visible to a naive user, a technically savvy person could easily retrieve this data from a browser. If an application exhibiting this behavior is used in a publicly accessible computer, then a malicious user can steal any data stored on the client.

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. A "*" can be used as the field value, which means that it cannot be determined from the HTTP headers what criteria was used to select content. An attacker can use this behavior to gain valuable insight into the application's business logic and use it to orchestrate targeted attacks.

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. It can be used to set "user-agent" as the criteria for negotiation. This might indicate that different content is available based on the User-Agent header in the HTTP request. An attacker could discover hidden application functionality or resources by submitting different values in the user-agent header.

Internal IP can be leaked due to:
1. Developer comments in application code
2. Unrestricted access to configuration files
3. Details revealed in verbose error messages
4. Server misconfiguration or failure to patch vulnerable servers causing an IP to be revealed in HTTP headers
Leaked IP addresses can allow an adversary to discover internal servers and gain access to restricted resources.

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

It is common practice to output the values of variables for debugging or testing purposes with code that is not intended to be shipped or remain active in the deployed application. When this sort of debug code is accidentally left in the application, the application might provide information to an attacker in unintended ways. Not all debug statements leak sensitive or private information. However, the presence of a debug statement often indicates that the surrounding code has been neglected and might be in a state of disrepair.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code sends a text based SMS.

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

This API requires the android.permission.SEND_SMS permission. If this permission is not requested by the application in the manifest file, the application will fail to send an SMS.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code reads contacts information stored on the device.

Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

Reading data from this content provider requires the android.permission.READ_CONTACTS permission. If this permission is not requested by the application in the manifest file, the application will fail to read contacts information.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code sends an intent with the android.provider.Telephony.SMS_RECEIVED action.

    Intent i = new Intent("android.provider.Telephony.SMS_RECEIVED");
    context.sendBroadcast(i);

Sending this intent requires the android.permission.BROADCAST_SMS permission. If this permission is not requested by the application in the manifest file, the application will fail to send the intent.

The AccessibleObject API allows the programmer to get around the access control checks provided by Java access specifiers. In particular it enables the programmer to allow a reflected object to bypass Java access controls and in turn change the value of private fields or invoke private methods, behaviors that are normally disallowed.

An internal information leak occurs when system data or debugging information is sent via logging or printing to a local file, console, or screen.

Example 1: The following XML contains system information about a device stored in a plist file. Among other values that are stored, the UDID key stores a Unique Device Identifier.

<?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>systemName</key>
  <string>John's iPhone</string>
  <key>systemInfo</key>
  <dict>
          <key>UDID</key>
          <string>2b6f0cc904d137be2e1730235f5664094b831186</string>
          <key>systemVersion</key>
          <string>4.2</string>
          <key>model</key>
          <string>iPhone</string>
          <key>localizedModel</key>
          <string>iPhone</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 system information and privacy are a concern, since plist files could be read by anyone in possession of the device.