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

Spring Security includes an HTTP firewall that helps protect the application by sanitizing requests that contain potentially malicious characters. Spring achieves this by including the HttpFirewall into its FilterChainProxy, which processes the requests before they are sent through the filter chain. Sprint Security uses the StrictHttpFirewall implementation by default.


Example: The following code relaxes the firewall policy to allow %2F and ; characters:

    <beans:bean id="httpFirewall" class="org.springframework.security.web.firewall.StrictHttpFirewall" p:allowSemicolon="true" p:allowUrlEncodedSlash="true"/>

Allowing potentially malicious characters can lead to vulnerabilities if these characters are incorrectly on inconsistently processed. For example, allowing semicolons enable path parameters (as defined in RFC 2396) which are not consistently processed by frontend web servers such as nginx and application servers such as Apache Tomcat. These inconsistencies may be used for path traversal attacks or access control bypasses.

Mismanagement of permissions increases the risk of unauthorized access to or modification of data and undermines service availability.

A service account is a special Google account used by an application or a VM instead of a person, which uses sensitive permissions to run automated processes or make API requests on behalf of end users. It should be carefully managed, controlled, and audited, so it can be trusted. Assigning a service account role to an IAM user, which typically represents a person, weakens the security control.

The function checkCallingOrSelfPermission() or checkCallingOrSelfUriPermission() determine whether the calling program has the required permission to access a certain service or a given URI. However, these functions should be used with care as they can grant access to malicious applications, lacking the appropriate permissions, by assuming your applications permissions.

This means a malicious application, without appropriate permissions, can bypass its permission check by using your application's permission to get access to otherwise denied resources. This can result in what is known as the confused deputy attack.

Some functions may enable a programmer to specify an explicit value for whether permission was allowed. This can then be abused to violate what the user wants and still assume the permission was given.

Example 1: The following code asks permission to use the user's location on Android while using WebView, yet uses the user's location whether or not permission to do so is granted. This is achieved by manually invoking the callback with true to specify that permission was given:

public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions$Callback callback){
  super.onGeolocationPermissionsShowPrompt(origin, callback);
  callback.invoke(origin, true, false);
}

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.

Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, exercise caution when defining the header because an overly permissive CORS policy can enable a malicious application to inappropriately communicate with the victim application, which can lead to spoofing, data theft, relay, and other attacks.

Example 1: The following is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Using the * as the value of the Access-Control-Allow-Origin header indicates that the application's data is accessible to JavaScript running on any domain.