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: 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: 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.

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 body sensors can pose a danger to user privacy and personal safety. Applications that require access to body sensors must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the BODY_SENSORS permission, which enables an application to access data from body or environmental sensors on the device or connected wearables.

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

Operations related to making and receiving telephone calls must not be performed without cause or consideration. Malicious software exploits these APIs to call premium-pay numbers, thereby stealing money from unwary users.

Example: The following code requests the complete voicemail number.

number = tm.getCompleteVoiceMailNumber(); 

Some permissions on Intents are there to be able to grant permissions to external programs that do not usually have that permission, such as FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION. If a malicious program is able to intercept this intent, it will then gain permission to read from or write to the specified URI. These can often be more susceptible to being intercepted if the intent is implicit rather than explicit.

Example 1: The following code sets the permission flag to enable writing to a URI within the Intent.

  myIntent.setFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

PL/SQL functions and procedures can be either AUTHID DEFINER or AUTHID CURRENT_USER. Functions and procedures with definer's rights execute under the privileges of the user that defines the code. This can allow updates and access to specific pieces of data without granting access to entire tables or schemas. With invoker's rights, or AUTHID CURRENT_USER, functions and procedures execute under the privileges of the user who invokes them. This does not allow a user to gain access to data it didn't already have access to. If no AUTHID clause is provided, the function or procedure defaults to definer's rights.

Functions and procedures are usually defined by SYS or another highly privileged user, making any exploits of the code potentially more dangerous.

PL/SQL packages can be either AUTHID DEFINER or AUTHID CURRENT_USER. Functions and procedures in a package with definer's rights execute under the privileges of the user that defines the package. This can allow updates and access to specific pieces of data without granting access to entire tables or schemas. In a package with invoker's rights, or AUTHID CURRENT_USER, functions and procedures execute under the privileges of the user who invokes them. This does not allow a user to gain access to data it didn't already have access to. If no AUTHID clause is provided, the package defaults to definer's rights.

Packages are usually defined by SYS or another highly privileged user, making any exploits of the code potentially more dangerous.

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.

Secure coding principles advocate making access specifiers as restrictive as possible. A method with a public access specifier means that any external code is allowed to call it. Public methods that perform privileged actions can be dangerous when code is shared in libraries or in environments where code can dynamically enter the system (e.g. Code Injection, Dangerous File Inclusion, File Upload, etc).

Example 1: In the following code, doPrivilegedOpenFile() is declared public and performs a privileged operation.

public static void doPrivilegedOpenFile(final String filePath) {
  final BadFileNamePrivilegedAction pa = new BadFileNamePrivilegedAction(filePath);

  FileInputStream fis = null;
  ...
  fis = (FileInputStream)AccessController.doPrivileged(pa);
  ...
}

Using the ALL PRIVILEGES or ALL option will grant the user all of the permissions that can be applied to an object. The programmer may not be aware of all of the privileges being granted.

Example: An administrator may want to give a user the ability to update the data in the procedure.

GRANT ALL ON employees TO john_doe;

In addition to the ability to select, update, add, and remove rows, john_doe now has permission to change the definition of the table.

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);
}