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 TestClass1 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

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

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

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

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