By default, Docker allows binding privileged ports to a container and if a port is not declared by the user then Docker maps the container port to one available in the 49153-65535 range. In many cases, certain ports need to be opened for running services and over time, the number of open ports may increase. Open ports increases the attack surface, particularly for services running with higher privileges. Make sure that you only open ports that are required for that specific service. When services do not require higher privileges, run them on port outside the privileged port range.

You can reconstruct a Dockerfile from a publicly available docker image using docker inspect and the history command, or by automating this process through a third-party tool. If sensitive information is added using the ADD/COPY command, an attacker can recreate each docker layer to obtain the information.

Using Volumes also can expose sensitive directories. If you need to use Volumes to persist data, avoid mounting sensitive directories.

When a Secure Shell (SSH) service is running within a container, it is difficult to manage access policies, keys, passwords, and security upgrades.

Unlike a regular message call, using delegatecall causes the code at the target address to be executed in the context of the calling address. delegatecall effectively enables the smart contract to dynamically load code from a different address at runtime, which is dangerous as the code at the target address can change any storage values and potentially take full control over the caller's balance.

Example 1: The following code uses delegatecall to execute code in the context of the calling address.

function forward(address callee, bytes _data) public {
    require(callee.delegatecall(_data));
}

Using a CDN to serve an application's dependent JavaScript offers many advantages over serving JavaScript from the application's own server. These benefits include increased performance and less code maintenance for the application owner. However, the application assumes that the CDN will deliver safe content to the browser. If an attacker compromises a CDN, the CDN will deliver malicious code to the user's browser. The user's browser is now executing code that the application cannot control or detect as malicious.

Example 1: The following ASPX code includes Microsoft's jQuery code by referencing the Microsoft CDN:

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

Example 2: The following ASPX code enables the automatic redirect of all ASP.NET framework script requests to the Microsoft Ajax CDN:

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

In Example 2, the ScriptManager control configures its ASPX page to automatically redirect any script requests to the appropriate CDN.

Adobe Flash has been associated with multiple vulnerabilities since its inception. Many of which can lead to Remote Code Execution and Cross-Site Scripting attacks that can compromise user and/or system data and privacy.

Adobe has deprecated Flash with an end-of-life set to the end of 2020. Many browsers have already disabled Adobe Flash support by default, for example, starting in Chrome 76 and Firefox 69. Furthermore, starting in December 2020, Chrome, Firefox, and Microsoft Edge will completely eliminate support for Flash.
Using a deprecated, possibly vulnerable version of the player to execute an application introduces unnecessary risk. Consider updating your application to replace Adobe Flash with safer, alternative technologies that provide similar functionality such as HTML5, WebGL, and WebAssembly. Use of safe alternative technologies is critical to protect users from known player vulnerabilities including Cross-Site Scripting, and Remote Code Execution (on the client machine).

If you are using Blaze DS to perform logging of any unexpected events, the services-config.xml descriptor file specifies a "Logging" XML element to describe various aspects of logging. It looks like the following:

Example 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

This target tag takes an optional attribute called level, which indicates the log level. If the debug level is set to too detailed a level, your application may write sensitive data to the log file.

Customer-managed encryption keys (CMEK) are not enabled for data at rest.

By default, Google Cloud uses randomly generated Data Encryption Keys (DEK) to encrypt data at rest. The CMEK feature allows organizations to use cryptographic keys of their choice to encrypt DEK. This gives organizations better control over and logging of encryption processes.

As such, CMEK is often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys
- Tamper-resistant hardware security module

Granting access or BigQuery roles to the special principal type such as allUsers and allAuthenticatedUsers gives anyone access to sensitive data.

Customer-managed encryption keys (CMEK) are not enabled for data at rest.

By default, Google Cloud uses randomly generated Data Encryption Keys (DEK) to encrypt data at rest. The CMEK feature allows organizations to use cryptographic keys of their choice to encrypt DEK. This gives organizations better control over and logging of encryption processes.

As such, CMEK is often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys
- Tamper-resistant hardware security module

Customer-managed encryption keys (CMEK) are not enabled for data at rest.

By default, Google Cloud uses randomly generated Data Encryption Keys (DEK) to encrypt data at rest. The CMEK feature allows organizations to use cryptographic keys of their choice to encrypt DEK. This gives organizations better control over and logging of encryption processes.

As such, CMEK is often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys
- Tamper-resistant hardware security module

DNSSEC prevents DNS spoofing by providing the ability to use digital signatures for DNS response validation. The DNSSEC of a Cloud DNS Domain is not enabled.

Example 1: The following example shows a Terraform configuration that disables DNSSEC on a Cloud DNS Domain by setting state to off in the dnssec_config block.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    state = "off"
    ...
  }
...
}

Customer-managed encryption keys (CMEK) are not enabled for data at rest.

By default, Google Cloud uses randomly generated Data Encryption Keys (DEK) to encrypt data at rest. The CMEK feature allows organizations to use cryptographic keys of their choice to encrypt DEK. This gives organizations better control over and logging of encryption processes.

As such, CMEK is often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys
- Tamper-resistant hardware security module

Granting allUsers or allAuthenticatedUsers a Cloud KMS CryptoKey role gives anyone access to sensitive data.

Customer-managed encryption keys (CMEK) are not enabled for data at rest.

By default, Google Cloud uses randomly generated Data Encryption Keys (DEK) to encrypt data at rest. The CMEK feature allows organizations to use cryptographic keys of their choice to encrypt DEK. This gives organizations better control over and logging of encryption processes.

As such, CMEK is often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys
- Tamper-resistant hardware security module

Database backups are critical to protect against data loss or corruption. Automated backups of a Cloud SQL database instance should be explicitly configured and enabled.

Example 1: The following example shows a Terraform configuration that disables database instance backup configurations by setting enabled to false.

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    backup_configuration {
      enabled = false
      ...
    }
  }
}

Failure to block unwanted network traffic expands a cloud service's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

By default, Terraform deploys a Google Cloud SQL Database instance that only accepts connections from private IP addresses. Optional Authorized Networks settings define acceptable ranges of public IP addresses.

Example 1: The following Terraform configuration sets value to 0.0.0.0/0 in the authorized_networks block. A CIDR block of /0 accepts connections from any IP address between 0.0.0.0 and 255.255.255.255.

resource "google_sql_database_instance" "db-demo" {
  ...
  settings {
  ...
    ip_configuration {
    ...
      authorized_networks {
        name  = "any ip"
        value = "0.0.0.0/0"
      }
    ...
    }
    ...
  }
  ...
}

Granting allUsers or allAuthenticatedUsers a Cloud Storage role gives anyone access to sensitive data.

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

The IAM-based access control reduces human errors and promotes efficiency. Enabling the OS Login permits the use of IAM roles to automate the lifecycle management of Linux accounts for accessing all Compute Engine instances in the same project or organization.

Example 1: The following example shows a Terraform configuration that disables the use of IAM roles to manage SSH access by setting enable-oslogin to false in the metadata argument.

resource "google_compute_instance" "compute-instance-demo" {
  ...
  metadata = {
    enable-oslogin = false
    ...
  }
  ...
}