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.

The program uses the equals() method to compare an object with null. This comparison will always return false, since the object is not null. (If the object is null, the program will throw a NullPointerException).

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

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

Every cloud service security feature is designed to prevent or mitigate a known threat. When disabled by intent or negligence, it offers no protection.

By default, if a GKE node repeatedly reports an unhealthy status over a given period, GKE initiates a repair process for that node. Disabling node auto-repair prevents timely and automated replacements of unhealthy nodes on which mission-critical workloads might run.

Example 1: The following Terraform configuration disables node auto-repair of a node pool by setting auto_repair to false in the management block.

resource "google_container_node_pool" "node-pool-demo" {
...
  management {
    auto_repair = false
    ...
  }
...
}

By default, GKE nodes run with Container-Optimized OS (COS). COS is an operating system image that is optimized to run GKE nodes on Google Compute Engine instances. Opting out of the default forgoes the benefits of enhanced security and efficiency.

Example 1: The following example Terraform configuration sets up a pool of GKE nodes that do not run COS because image_type is set to a non-COS image in the node_config block.

resource "google_container_node_pool" "node_pool_demo" {
  ...
  node_config {
    image_type = "UBUNTU"
    ...
  }
  ...
}

By default, GKE automatically upgrades Kubernetes nodes to newer stable versions. Automatic upgrades, which ensure timely patching of known software vulnerabilities, are disabled.

Example 1: The following example Terraform configuration disables automatic upgrades of Kubernetes nodes by setting auto_upgrade to false in the management block.

resource "google_container_node_pool" "node_pool_demo" {
...
  management {
    auto_upgrade = false
    ...
  }
...
}