Java APIs that perform tasks using the immediate caller's class loader check should be used with caution. These APIs bypass the SecurityManager check that ensures all callers in the execution chain have been granted the requisite security permission. Access checks against the immediate caller's class loader alone can result in privilege escalation issues whereby some caller in the execution chain is able to access resources without the required permissions. These APIs, thus, should not be invoked on behalf of untrusted code, as it may compromise system security.



Java Applets from an untrusted source or in an untrusted environment with access to these APIs can execute malicious code and compromise system security.

Salesforce applications use sharing rules to control user permissions and access to database records. However, user sharing rules are not always enforced in Apex because Apex classes can be declared with different sharing keywords that change the way the rules are enforced. A class can be declared with one of three different sharing keywords:

- with sharing: The user sharing rules will be enforced.
- without sharing: The sharing rules will not be enforced.
- inherited sharing: The sharing rules of the calling class will be enforced. When the calling class does not specify a sharing keyword, or when the class itself is an entrypoint such as a Visualforce controller, the user sharing rules will be enforced by default.

When none of the sharing keywords are declared, the class will inherit the sharing mode of the calling class if there is one. Otherwise, sharing rules will not be enforced.

Example 1: The following three Apex classes all have unsafe sharing keywords for their database query calls.

    public class MyClass1 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public without sharing class MyClass2 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public inherited sharing class MyClass3 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

Both MyClass1 and MyClass2 are unsafe because the records can be retrieved without the enforcement of user sharing rules.

MyClass3 is safer because it enforces sharing rules by default. However, unauthorized access can still be granted if function getAllTheSecrets() is called in a class that explicitly declares without sharing.

A single <security constraint> element suggests the program does not employ role-based access control, which is commonly accepted best practice for protecting sensitive operations in secure web applications. If the application provides access to sensitive operations or data, there might not be sufficient controls in place to prevent unauthorized users from gaining access. Furthermore, if there is a wildcard (*) in the <url-pattern>, it can be an indication that the pattern is overly broad.

Many applications use cookies to communicate a user's session identifier. When the application is accessed over HTTPS, cookies are protected (attackers are unable to sniff them). But if developers allow HTTP access to non-sensitive parts of the application, the session identifier can be stolen. When a user browses to an unprotected part of the site, the cookie, containing the session ID, is sent in the clear. If attackers sniff the traffic, they can see the session ID and use it to take control of the user's session.


The following example shows a configuration that mixes insecure and secure channels:

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

Acegi Security allows for temporarily replacing the Authentication object in the SecurityContext during the secure object callback phase. This only occurs if the original Authentication object was successfully processed by the AuthenticationManager and AccessDecisionManager. The RunAsManager creates this Authentication object.
Typically developers use RunAsManager to configure one or more additional roles for an authenticated user for the duration of a method invocation. This is useful for a secure bean that needs to access a remote application. Since the remote application might demand different credentials, this allows translating between calling roles and those needed by the remote application so that the remote access can succeed. The new Authentication object (called RunAsUserToken) will be simply accepted as a valid Authentication object without any further authentication or authorization check.
Adding new roles or privileges to the new Authentication object has the potential to temporarily elevate the user's privileges, allowing the user to take an unauthorized action.
The following configuration shows using RunAsManager to add the role "UBER_BOSS" to a user who has the role "ROLE_PEON", thus temporarily elevating this user to have manager privileges, which enables all peons to get data from the PrivateCatalog.

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

While it is a good idea to define separate read and write permissions for content providers, defining only the writePermission could be misleading. Due to the nature of SQL, generating true write-only queries is generally impossible: even when the user does not have direct access to the data, an attacker may reconstruct the stored data by manipulating the where clause.

Example 1: The following is an example of a content provider declared with only the writePermission.

 <provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/> 

Receiver registered without the broadcaster permission will receive messages from any broadcaster. If these messages contain malicious data or come from a malicious broadcaster, the application may be compromised.

Example 1: The following code registers a receiver without specifying the broadcaster permission.

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

Any application can access public components that are not explicitly assigned an access permission in their manifest definition.

The default value of the exported attribute for the activity, receiver, and service components in an Android application depends on the presence or absence of an intent-filter. Presence of an intent-filter implies, the component is intended for external use, thus setting the exported attribute to true. This component is now accessible to any other applications on the Android platform.

Example 1: The following is an example of an Android activity with an intent-filter and no explicit access permission set.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

This activity can be exploited by malicious applications.

Any application can access public components that are not explicitly assigned an access permission in their manifest definition. Android content providers are exported by default for applications that set either android:minSdkVersion or android:targetSdkVersion to "16" or earlier. For applications that set either of these attributes to "17" or later, the default is "false".

Example 1: The following is an example of an Android content provider declared without an explicit access permission or exported flag.

 <provider android:name=".ContentProvider"/> 

Android relies on a security Provider to provide secure network communications. However, from time to time, vulnerabilities are found in the default security provider. To protect against these vulnerabilities, Google Play services provides a way to automatically update a device's security provider to protect against known exploits. By calling Google Play services methods, your app can ensure that it's running on a device that has the latest updates to protect against known exploits.

The Network Security Configuration feature lets apps customize their network security settings in a safe, declarative configuration file without modifying app code. These settings can be configured for specific domains and for a specific app. The key capabilities of this feature are as follows:
- Custom trust anchors: Customize which Certificate Authorities (CA) are trusted for an app's secure connections. For example, trusting particular self-signed certificates or restricting the set of public CAs that the app trusts.
- Debug-only overrides: Safely debug secure connections in an app without added risk to the installed base.
- Cleartext traffic opt-out: Protect apps from accidental usage of cleartext traffic.
- Certificate pinning: Restrict an app's secure connection to particular certificates.

Broadcasts sent without the receiver permission are accessible to any receiver. If these broadcasts contain sensitive data or reach a malicious receiver, the application may be compromised.

Example 1: The following code sends a broadcast without specifying the receiver permission.

...
context.sendBroadcast(intent);
...

System broadcasts can be sent to private components. Components need to be public to receive non-system broadcasts from third-parties. By registering to receive both system and non-system broadcasts in a single component, some of the functionality of the component (the system portion) is unnecessarily exposed to third parties.

When declaring a custom permission, there are four options for specifying permission's protection level: normal, dangerous, signature, and signature or system. Normal permissions are granted to any application that requests them. Dangerous permissions are granted only after user confirmation. Signature permissions are granted only to applications signed by the same developer key as the package that defines the permission. Signature or system permissions are similar to signature permissions, but are also granted to packages in the Android system image.

Example 1: The following is an example of a custom permission declared with the normal protection level.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

A content provider declared with the combined read and write permission will be accessible to the entities that request either read or write access to the provider. However, in many cases, just like in the case of files on a file system, entities that need read access to the data stored by the provider should not be allowed to modify the data. Setting the permission attribute does not allow to distinguish between data users and interactions that affect the data's integrity.

Example 1: The following is an example of a content provider declared with the combined read and write access permission.

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

Sticky broadcasts cannot be secured with a permission and therefore are accessible to any receiver. If these broadcasts contain sensitive data or reach a malicious receiver, the application may be compromised.

Example 1: The following code sends a sticky broadcast.

...
context.sendStickyBroadcast(intent);
...

Defining new permissions on the android.permission namespace can have unexpected consequences when the OS is updated. If the newer version of the OS defines the exact same permission, the Android Package Management Service (PMS) will silently grant the permission to the app without asking the user allowing privilege escalation attacks.

As this component only expects to receive broadcast messages from the system and not other components, it should be private (inaccessible to other components.)

Hardware and device specific identifiers persist across data wipes and factory resets. One should not rely on these to generate unique identifiers that are used to authorize or authenticate users.

Moreover, leakage of universally unique identifiers, that can be associated with personal information, pose a threat to user privacy and security.

Certain frameworks such as AngularJS limit the protocols that may be set for links to other sites and images. This is primarily to prevent inline JavaScript from running, which may lead to additional cross-site scripting vulnerabilities within the application.

Example 1: The following changes the default allow list of protocols in AngularJS to also allow image HTML elements to allow inline JavaScript.

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});