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 user's calendar can pose a danger to user privacy and personal safety. Applications must treat calendar data as sensitive and manage it with the utmost caution to maintain privacy.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CALENDAR permission, which enables an application to read the user's calendar data.

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

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CALENDAR permission, which enables an application to write to the user's calendar data.

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

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

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CALL_LOG permission, which enables an application to read the user's call log.

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

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CALL_LOG permission, which enables an application to write to the user's call log.

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

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

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the CAMERA permission, which enables an application to access the device's camera.

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

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 contacts information can pose a danger to user privacy and personal safety. Applications must treat contacts data as sensitive and manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CONTACTS permission, which enables an application to read the user's contacts data.

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

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CONTACTS permission, which enables an application to write to the user's contacts data.

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

Example 3: The <uses-permission .../> element of AndroidManifest.xml declares usage of the GET_ACCOUNTS permission, which enables an application to access the user's email and online accounts stored in the Account Manager. Sensitive data such as account IDs, email addresses, and phone numbers can be accessed with this permission.

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

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

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

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

An information leak occurs when system data or debug information leaves the program through an output stream or logging function.



This parameter tells Apache Axis 2 to send fault messages to clients. Fault messages contain stack traces and in some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.

An information leak occurs when system data or debug information leaves the program through an output stream or logging function.

In this case, the Struts 2 Config Browser is configured in the maven pom.xml file and so it is available and deployed along the application.

The Config Browser plugin is a debugging tool to help view an application's configuration at runtime. It is very useful when debugging problems that could be related to configuration issues but it exposes too many details that may help an attacker to map and model the application.

Path Normalization Conflict can occur in systems with multi-layered architecture where the components have different approaches to Path Normalization process. An attacker can bypass allow list and deny list ACL rules on intermediate components and as a result sensitive resources are unexpectedly exposed.
Example 1:
Using the proxy_pass directive, NGINX can forward all requests for /publicfolder to the Tomcat server. The developer expects that only this folder is accessible to users. However, an attacker can send the next request http://targetserver/publicfolder/..;/manager/html
NGINX considers ..; to be a folder name so the path matches the rule and this request is forwarded to the Tomcat server.
The Tomcat server considers ..; to indicate parent directory and will map the request to /publicfolder/../manager/html, giving the attacker access to the manager app of Tomcat server.

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

HTML5 provides a new ability to do simple input form fields validation. One can specify whether an input form field is required by using the required attribute. Specifying the field type makes sure that the input is checked against its type. One can even supply a customizable pattern attribute that checks the input against a regular expression. However, this validation gets disabled when adding a novalidate attribute on a form tag and a formnovalidate attribute on a submit input tag.

Example 1: The following sample disables form validation via a novalidate attribute.

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

Example 2: The following sample disables form validation via a formnovalidate attribute.

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

HTML forms with disabled validation are not user-friendly and can potentially expose the server to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection.

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. It can be used to set "accept-language" as the criteria for negotiation. This might indicate that different content is available based on the Accept-Language header in the HTTP request. An attacker could access information not intended for public consumption by submitting different values in the Accept-Language header.

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

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.

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