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

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.

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>

By default, task flows in a Fusion application are not directly accessible from a GET request: whenever a URL attempts to invoke the task flow, it receives an HTTP 403 status code. However, relying on an implicit setting always lacks clarity and can potentially lead to unwanted behavior if the default setting changes underneath.

Example 1: The following snippet from a task flow definition file shows an example of a task flow configured with the implicit default url-invoke-disallowed setting.

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...