In a regular JSF application, values are converted and validated using converters and validators specified by the UI components. The conversion and validation itself happens when the page is submitted. A bookmarkable view in a Fusion application results in no page submission, and therefore no similar conversion or validation is performed by default.

Example 1: The following configuration file snippet shows a sample bookmarkable view that is configured to perform no conversion or validation of the paramName URL parameter.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

The values of attributes for Oracle ADF Faces components can ordinarily be set only on the server. However, a number of components allow the developer to define a list of attributes that can be set on the client. unsecure attribute of these components can specify such a list.

Currently, the only attribute that can appear inside the unsecure attribute is disabled, and it allows the client to define which components are enabled and which ones are not. It is never a good idea to let the client control the values of attributes that should only be settable on the server.

Example: The following code demonstrates an inputText component that collects password information from the user and uses the unsecure attribute.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Storing encryption keys in static class fields allows easy recovery by an entity that can access the process memory (e.g. rooted device) or process memory dumps (e.g. crash dumps).

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"/> 

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.

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.