Platforms like Node.js and MongoDB server rely solely on JavaScript for all critical server-side operations. MongoDB uses JavaScript internally for scripting server-side operation routines (such as Map/Reduce), to perform group-by operations, or to populate query content in the $where clause. Node.js is used to build fast and scalable network applications in JavaScript.
Using JavaScript programmers can dynamically invoke server-side routines, construct procedures dynamically and perform network operations.

A server-side injection vulnerability can occur when:
1. The user supplied input is not validated thoroughly before being used to invoke server-side JavaScript procedures, an attacker can supply malicious input specially crafted to modify the behavior of a script in an unintended way.
2. Using unvalidated user input directly in 'eval' calls
3. Appending user input to dynamically generated JavaScript code

These issues pose severe risks to the application:
Denial of Service (DoS):
DoS attacks against traditional web applications involves sending thousands of HTTP requests. Applications vulnerable to server-side JavaScript injection can attacked using a single line of code. For example, by injecting while(1) into an eval function, the attacker could trigger excessive resource consumption and severely impact the application availability.
Unauthorized File System Access:
Attackers can abuse the file system access APIs like CommonJS and the 'fs' module. The following payload could allow an attacker to read arbitrary file contents.

response.end(require('fs').readFileSync(filename))

NoSQL injection
Applications that dynamically build a $where clause using unvalidated user input can be exploited by injecting malicious javascript code to alter the query and extract information from the database or injecting a call to the sleep function and affecting the availability of the application.

1';sleep(33333);var%20a='

Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

If access restrictions are not implemented correctly, an attacker can modify the file name or extension in a specific manner to bypass them. The attacker can, for instance, change the extension from lower to upper case and bypass restrictions that fails to account for case sensitivity. This can lead to a sensitive information disclosure and the recovery of sensitive data such as application source code, database authentication credentials, etc.

A URL map is a set of rules to route incoming HTTP(S) requests to specific backend services. By default, a URL map accepts unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines a URL map that allows clients to use HTTP for communication by setting https_redirect to false.

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

Mismanagement of permissions increases the risk of unauthorized access to or modification of restricted data.

To define user permission for access to buckets and objects in buckets, Google Cloud Storage offers two systems: Access Control Lists (ACLs) and Identity and Access Management (IAM). IAM can be used throughout Google Cloud, while only Cloud Storage supports ACLs. Enabling Uniform Bucket-level Access prevents ACLs from granting permission. This ensures IAM is the only system to manage all access control of Google Cloud resources.

Example 1: The following Terraform configuration permits using ACLs alongside IAM to grant access to the storage bucket by setting uniform_bucket_level_access to false.

resource "google_storage_bucket" "bucket-demo" {
...
  uniform_bucket_level_access = false
...
}

By default, Attribute-Based Access Control (ABAC) is disabled on new clusters that run GKE version 1.8 and later. ABAC can statically grant a specific user or a group access to a resource in addition to those provided by Role-Based Access Control (RBAC) or Identity and Access Management (IAM). This complicates authorization administration and undermines the centralized access control.

Example 1: The following example shows a Terraform configuration that enables legacy ABAC authorization on a GKE cluster by setting enable_legacy_abac to true.

resource "google_container_cluster" "container_cluster_demo" {
...
  enable_legacy_abac = true
...
}

Directly accessing Java Server Pages (JSPs) in applications built using web frameworks, such as Struts or Spring, that use actions or servlets to delegate requests to JSPs can result in unhandled exceptions and system information leaks. Poorly implemented or configured application servers have been co-opted into leaking source code details using specially crafted requests, such as http://host/page.jsp%00 or http://host/page.js%2570. Even worse, if an application permits users to upload arbitrary files, attackers may use this mechanism to upload malicious code in the form of a JSP and request the uploaded page to cause the malicious code to execute on the server.

Example 1: The following example shows a poorly constructed security constraint that explicitly allows direct access to JSPs with a '*' in the role name, which indicates that all users are allowed access the corresponding web resources.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

Calling Object.equals() against an array is a mistake in most cases, since this will check the equality of the arrays' addresses, instead of the equality of the arrays' elements, and should usually be replaced by java.util.Arrays.equals().

Example 1: The following tries to check two arrays using the Object.equals() function.

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

This will almost always result in code that is never executed, unless at some point there is an assignment of one array to the other.