SonarQube Vulnerability Report

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

To provide communication security over a network, SSL and TLS are generally used. However, it is important to note that the following protocols are all considered weak by the cryptographic community, and are officially deprecated:

• SSL versions 1.0, 2.0 and 3.0
• TLS versions 1.0 and 1.1

When these unsecured protocols are used, it is best practice to expect a breach: that a user or organization with malicious intent will perform mathematical attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in Databases

Code examples

The following code samples are equivalent For Azure Database for MySQL servers, Azure Database for PostgreSQL servers, and Azure Database for MariaDB servers.

For all of these, there is no minimal TLS version enforced by default.

Noncompliant code example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DBforMySQL/servers",
      "apiVersion": "2017-12-01",
      "name": "example",
      "properties": {
        "minimalTlsVersion": "TLS1_0"
      }
    }
  ]
}

resource mysqlDbServer 'Microsoft.DBforMySQL/servers@2017-12-01' = {
  name: 'example'
  properties: {
    minimalTlsVersion: 'TLS1_0' // Noncompliant
  }
}

Compliant solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DBforMySQL/servers",
      "apiVersion": "2017-12-01",
      "name": "example",
      "properties": {
        "minimalTlsVersion": "TLS1_2"
      }
    }
  ]
}

resource mysqlDbServer 'Microsoft.DBforMySQL/servers@2017-12-01' = {
  name: 'example'
  properties: {
    minimalTlsVersion: 'TLS1_2'
  }
}

How does this work?

As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The best choices at the moment are the following.

Use TLS v1.2 or TLS v1.3

Even though TLS V1.3 is available, using TLS v1.2 is still considered good and secure practice by the cryptography community.

The use of TLS v1.2 ensures compatibility with a wide range of platforms and enables seamless communication between different systems that do not yet have TLS v1.3 support.

The only drawback depends on whether the framework used is outdated: its TLS v1.2 settings may enable older and insecure cipher suites that are deprecated as insecure.

On the other hand, TLS v1.3 removes support for older and weaker cryptographic algorithms, eliminates known vulnerabilities from previous TLS versions, and improves performance.

Resources

Articles & blog posts

• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

Enabling public network access to cloud resources can affect an organization’s ability to protect its data or internal operations from data theft or disruption.

Depending on the component, inbound access from the Internet can be enabled via:

• a boolean value that explicitly allows access to the public network.
• the assignment of a public IP address.
• database firewall rules that allow public IP ranges.

Deciding to allow public access may happen for various reasons such as for quick maintenance, time saving, or by accident.

This decision increases the likelihood of attacks on the organization, such as:

• data breaches.
• intrusions into the infrastructure to permanently steal from it.
• and various malicious traffic, such as DDoS attacks.

Ask Yourself Whether

This cloud resource:

• should be publicly accessible to any Internet user.
• requires inbound traffic from the Internet to function properly.

There is a risk if you answered no to any of those questions.

Recommended Secure Coding Practices

Avoid publishing cloud services on the Internet unless they are intended to be publicly accessible, such as customer portals or e-commerce sites.

Use private networks (and associated private IP addresses) and VPC peering or other secure communication tunnels to communicate with other cloud components.

The goal is to prevent the component from intercepting traffic coming in via the public IP address. If the cloud resource does not support the absence of a public IP address, assign a public IP address to it, but do not create listeners for the public IP address.

Sensitive Code Example

Using publicNetworkAccess to control access to resources:

resource exampleSite 'Microsoft.Web/sites@2020-12-01' = {
  name: 'example-site'
  properties: {
    publicNetworkAccess: 'Enabled'
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2020-12-01",
      "name": "example-site",
      "properties": {
        "siteConfig": {
          "publicNetworkAccess": "Enabled"
        }
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2020-12-01",
      "name": "example",
      "resources": [
        {
          "type": "config",
          "apiVersion": "2020-12-01",
          "name": "example-config",
          "properties": {
            "publicNetworkAccess": "Enabled"
          }
        }
      ]
    }
  ]
}

Using IP address ranges to control access to resources:

resource exampleFirewall 'Microsoft.Sql/servers/firewallRules@2014-04-01' = {
  name: 'example-firewall'
  properties: {
    startIpAddress: '0.0.0.0'
    endIpAddress: '255.255.255.255'
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Sql/servers/firewallRules",
      "apiVersion": "2014-04-01",
      "name": "example-firewall",
      "properties": {
        "startIpAddress": "0.0.0.0",
        "endIpAddress": "255.255.255.255"
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Sql/servers",
      "apiVersion": "2014-04-01",
      "name": "example-database",
      "resources": [
        {
          "type": "firewallRules",
          "apiVersion": "2014-04-01",
          "name": "example-firewall",
          "properties": {
            "startIpAddress": "0.0.0.0",
            "endIpAddress": "255.255.255.255"
          }
        }
      ]
    }
  ]
}

Compliant Solution

Using publicNetworkAccess to control access to resources:

resource exampleSite 'Microsoft.Web/sites@2020-12-01' = {
  name: 'example-site'
  properties: {
    publicNetworkAccess: 'Disabled'
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2020-12-01",
      "name": "example-site",
      "properties": {
        "siteConfig": {
          "publicNetworkAccess": "Disabled"
        }
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2020-12-01",
      "name": "example-site",
      "resources": [
        {
          "type": "config",
          "apiVersion": "2020-12-01",
          "name": "example-config",
          "properties": {
            "publicNetworkAccess": "Disabled"
          }
        }
      ]
    }
  ]
}

Using IP address ranges to control access to resources:

resource exampleFirewall 'Microsoft.Sql/servers/firewallRules@2014-04-01' = {
  name: 'example-firewall'
  properties: {
    startIpAddress: '192.168.0.0'
    endIpAddress: '192.168.255.255'
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Sql/servers/firewallRules",
      "apiVersion": "2014-04-01",
      "name": "example-firewall",
      "properties": {
        "startIpAddress": "192.168.0.0",
        "endIpAddress": "192.168.255.255"
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Sql/servers",
      "apiVersion": "2014-04-01",
      "name": "example-database",
      "resources": [
        {
          "type": "firewallRules",
          "apiVersion": "2014-04-01",
          "name": "example-firewall",
          "properties": {
            "startIpAddress": "192.168.0.0",
            "endIpAddress": "192.168.255.255"
          }
        }
      ]
    }
  ]
}

See

• AWS Documentation - Amazon EC2 instance IP addressing
• AWS Documentation - Public and private replication instances
• AWS Documentation - VPC Peering
• CWE - CWE-284 - Improper Access Control
• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Disabling Managed Identities can reduce an organization’s ability to protect itself against configuration faults and credential leaks.

Authenticating via managed identities to an Azure resource solely relies on an API call with a non-secret token. The process is inner to Azure: secrets used by Azure are not even accessible to end-users.

In typical scenarios without managed identities, the use of credentials can lead to mistakenly leaving them in code bases. In addition, configuration faults may also happen when storing these values or assigning them permissions.

By transparently taking care of the Azure Active Directory authentication, Managed Identities allow getting rid of day-to-day credentials management.

Ask Yourself Whether

The resource:

• Needs to authenticate to Azure resources that support Azure Active Directory (AAD).
• Uses a different Access Control system that doesn’t guarantee the same security controls as AAD, or no Access Control system at all.

There is a risk if you answered yes to all of those questions.

Recommended Secure Coding Practices

Enable the Managed Identities capabilities of this Azure resource. If supported, use a System-Assigned managed identity, as:

• It cannot be shared across resources.
• Its life cycle is deeply tied to the life cycle of its Azure resource.
• It provides a unique independent identity.

Alternatively, User-Assigned Managed Identities can also be used but don’t guarantee the properties listed above.

Sensitive Code Example

Using ARM templates:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.ApiManagement/service",
            "apiVersion": "2022-09-01-preview",
            "name": "apiManagementService"
        }
    ]
}

Using Bicep:

resource sensitiveApiManagementService 'Microsoft.ApiManagement/service@2022-09-01-preview' = {
  name: 'apiManagementService'
  // Sensitive: no Managed Identity is defined
}

Compliant Solution

Using ARM templates:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.ApiManagement/service",
            "apiVersion": "2022-09-01-preview",
            "name": "apiManagementService",
            "identity": {
                "type": "SystemAssigned"
            }
        }
    ]
}

Using Bicep:

resource sensitiveApiManagementService 'Microsoft.ApiManagement/service@2022-09-01-preview' = {
  name: 'apiManagementService'
  identity: {
    type: 'SystemAssigned'
  }
}

See

• Azure AD Documentation - Managed Identities Overview
• Azure AD Documentation - Managed Identities Best Practices
• Azure AD Documentation - Services that support managed identities

Azure Resource Manager templates define parameters as a way to reuse templates in different environments. Secure parameters (secure strings and secure objects) should not be assigned a default value.

Why is this an issue?

Parameters with the type securestring and secureObject are designed to pass sensitive data to the resources being deployed. Unlike other data types, they cannot be accessed after the deployment is completed. They can neither be logged nor used as an output.

Secure parameters can be assigned a default value which will be used if the parameter is not supplied. This default value is not protected and is stored in cleartext in the deployment history.

What is the potential impact?

If the default value contains a secret, it will be disclosed to all accounts that have read access to the deployment history.

How to fix it in ARM templates

Code examples

Noncompliant code example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "secretValue": {
      "type": "securestring",
      "defaultValue": "S3CR3T"
    }
  }
}

Compliant solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "secretValue": {
      "type": "securestring"
    }
  }
}

Resources

Documentation

• Data types in ARM templates
• ARM template best practices - Security recommendations for parameters

Standards

• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• CWE - CWE-532 - Insertion of Sensitive Information into Log File

When using nested deployments in Azure, template expressions can be evaluated within the scope of the parent template or the scope of the nested template. If such a template expression evaluates a secure value of the parent template, it is possible to expose this value in the deployment history.

Why is this an issue?

Parameters with the type securestring and secureObject are designed to pass sensitive data to the resources being deployed. Secure parameters cannot be accessed after the deployment is completed: they can neither be logged nor used as an output.

When used in nested deployments, however, it is possible to embed secure parameters in such a way they can be visible afterward.

What is the potential impact?

If the nested deployment contains a secure parameter in this way, then the value of this parameter may be readable in the deployment history. This can lead to important credentials being leaked to unauthorized accounts.

How to fix it in ARM Templates

By setting properties.expressionEvaluationOptions.scope to Inner in the parent template, template evaluations are limited to the scope of the nested template. This makes it impossible to expose secure parameters defined in the parent template.

Code examples

Noncompliant code example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "adminUsername": {
      "type": "securestring",
      "defaultValue": "[newGuid()]"
    }
  },
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2022-09-01",
      "properties": {
        "mode": "Incremental",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "1.0.0.0",
          "resources": [
            {
              "name": "example",
              "type": "Microsoft.Compute/virtualMachines",
              "apiVersion": "2022-11-01",
              "properties": {
                "osProfile": {
                  "adminUsername": "[parameters('adminUsername')]"
                }
              }
            }
          ]
        }
      }
    }
  ]
}

Compliant solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2022-09-01",
      "properties": {
        "expressionEvaluationOptions": {
          "scope": "Inner"
        },
        "mode": "Incremental",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "1.0.0.0",
          "parameters": {
            "adminUsername": {
              "type": "securestring",
              "defaultValue": "[newGuid()]"
            }
          },
          "resources": [
            {
              "name": "example",
              "type": "Microsoft.Compute/virtualMachines",
              "apiVersion": "2022-11-01",
              "properties": {
                "osProfile": {
                  "adminUsername": "[parameters('adminUsername')]"
                }
              }
            }
          ]
        }
      }
    }
  ]
}

Resources

Documentation

• Microsoft Learn - Microsoft.Resources/deployments

Standards

• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• CWE - CWE-532 - Insertion of Sensitive Information into Log File

Clear-text protocols such as ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

• sensitive data exposure
• traffic redirected to a malicious endpoint
• malware-infected software update or installer
• execution of client-side code
• corruption of critical information

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

• bypassing isolation mechanisms
• compromising a component of the network
• getting the credentials of an internal IAM account (either from a service account or an actual person)

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

• CVE-2019-6169
• CVE-2019-12327
• CVE-2019-11065

Ask Yourself Whether

• Application data needs to be protected against tampering or leaks when transiting over the network.
• Application data transits over an untrusted network.
• Compliance rules require the service to encrypt data in transit.
• OS-level protections against clear-text traffic are deactivated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Make application data transit over a secure, authenticated and encrypted protocol like TLS or SSH. Here are a few alternatives to the most common clear-text protocols:
  • Use sftp, scp, or ftps instead of ftp.
  • Use https instead of http.

It is recommended to secure all transport channels, even on local networks, as it can take a single non-secure connection to compromise an entire application or system.

Sensitive Code Example

For Microsoft.Web/sites:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "name": "example",
      "apiVersion": "2022-09-01",
      "properties": {
        "httpsOnly": false
      }
    }
  ]
}

resource symbolicname 'Microsoft.Web/sites@2022-03-01' = {
  properties: {
    httpsOnly: false // Sensitive
  }
}

For Microsoft.Web/sites/config:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites/config",
      "name": "sites/example",
      "apiVersion": "2022-09-01",
      "properties": {
        "ftpsState": "AllAllowed"
      }
    }
  ]
}

resource symbolicname 'Microsoft.Web/sites/config@2022-09-01' = {
  properties: {
    ftpsState: 'AllAllowed' // Sensitive
  }
}

For Microsoft.Storage/storageAccounts:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "example",
      "apiVersion": "2022-09-01",
      "properties": {
        "supportsHttpsTrafficOnly": false
      }
    }
  ]
}

resource symbolicname 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  properties: {
    supportsHttpsTrafficOnly: false // Sensitive
  }
}

For Microsoft.ApiManagement/service/apis:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.ApiManagement/service/apis",
      "name": "service/example",
      "apiVersion": "2022-08-01",
      "properties": {
        "protocols": ["http"]
      }
    }
  ]
}

resource symbolicname 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
  properties: {
    protocols: ['http'] // Sensitive
  }
}

For Microsoft.Cdn/profiles/endpoints:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Cdn/profiles/endpoints",
      "name": "profiles/example",
      "apiVersion": "2021-06-01",
      "properties": {
        "isHttpAllowed": true
      }
    }
  ]
}

resource symbolicname 'Microsoft.Cdn/profiles/endpoints@2021-06-01' = {
  properties: {
    isHttpAllowed: true // Sensitive
  }
}

For Microsoft.Cache/redisEnterprise/databases:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Cache/redisEnterprise/databases",
      "name": "redisEnterprise/example",
      "apiVersion": "2022-01-01",
      "properties": {
        "clientProtocol": "Plaintext"
      }
    }
  ]
}

resource symbolicname 'Microsoft.Cache/redisEnterprise/databases@2022-01-01' = {
  properties: {
    clientProtocol: 'Plaintext' // Sensitive
  }
}

For Microsoft.DBforMySQL/servers, Microsoft.DBforMariaDB/servers, and Microsoft.DBforPostgreSQL/servers:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DBforMySQL/servers",
      "name": "example",
      "apiVersion": "2017-12-01",
      "properties": {
        "sslEnforcement": "Disabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DBforMySQL/servers@2017-12-01' = {
  properties: {
    sslEnforcement: 'Disabled' // Sensitive
  }
}

Compliant Solution

For Microsoft.Web/sites:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "name": "example",
      "apiVersion": "2022-09-01",
      "properties": {
        "httpsOnly": true
      }
    }
  ]
}

resource symbolicname 'Microsoft.Web/sites@2022-03-01' = {
  properties: {
    httpsOnly: true
  }
}

For Microsoft.Web/sites/config:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites/config",
      "name": "sites/example",
      "apiVersion": "2022-09-01",
      "properties": {
        "ftpsState": "FtpsOnly"
      }
    }
  ]
}

resource symbolicname 'Microsoft.Web/sites/config@2022-09-01' = {
  properties: {
    ftpsState: 'FtpsOnly'
  }
}

For Microsoft.Storage/storageAccounts:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "example",
      "apiVersion": "2022-09-01",
      "properties": {
        "supportsHttpsTrafficOnly": true
      }
    }
  ]
}

resource symbolicname 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

For Microsoft.ApiManagement/service/apis:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.ApiManagement/service/apis",
      "name": "service/example",
      "apiVersion": "2022-08-01",
      "properties": {
        "protocols": ["https"]
      }
    }
  ]
}

resource symbolicname 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
  properties: {
    protocols: ['https']
  }
}

For Microsoft.Cdn/profiles/endpoints:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Cdn/profiles/endpoints",
      "name": "profiles/example",
      "apiVersion": "2021-06-01",
      "properties": {
        "isHttpAllowed": false
      }
    }
  ]
}

resource symbolicname 'Microsoft.Cdn/profiles/endpoints@2021-06-01' = {
  properties: {
    isHttpAllowed: false
  }
}

For Microsoft.Cache/redisEnterprise/databases:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Cache/redisEnterprise/databases",
      "name": "redisEnterprise/example",
      "apiVersion": "2022-01-01",
      "properties": {
        "clientProtocol": "Encrypted"
      }
    }
  ]
}

resource symbolicname 'Microsoft.Cache/redisEnterprise/databases@2022-01-01' = {
  properties: {
    clientProtocol: 'Encrypted'
  }
}

For Microsoft.DBforMySQL/servers, Microsoft.DBforMariaDB/servers, and Microsoft.DBforPostgreSQL/servers:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DBforMySQL/servers",
      "name": "example",
      "apiVersion": "2017-12-01",
      "properties": {
        "sslEnforcement": "Enabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DBforMySQL/servers@2017-12-01' = {
  properties: {
    sslEnforcement: 'Enabled'
  }
}

See

• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• CWE - CWE-319 - Cleartext Transmission of Sensitive Information
• Google, Moving towards more secure web
• Mozilla, Deprecating non secure http

Using unencrypted cloud storages can lead to data exposure. In the case that adversaries gain physical access to the storage medium they are able to access unencrypted information.

Ask Yourself Whether

• The service contains sensitive information that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt cloud storages that contain sensitive information.

Sensitive Code Example

For Microsoft.AzureArcData/sqlServerInstances/databases:

Disabled encryption on SQL service instance database:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "databases/example",
      "type": "Microsoft.AzureArcData/sqlServerInstances/databases",
      "apiVersion": "2023-03-15-preview",
      "properties": {
        "databaseOptions": {
          "isEncrypted": false
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.AzureArcData/sqlServerInstances/databases@2023-03-15-preview' = {
  properties: {
    databaseOptions: {
      isEncrypted: false
    }
  }
}

For Microsoft.Compute/disks, encryption is disabled by default.

For Microsoft.Compute/snapshots:

Disabled disk encryption with settings collection:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/snapshots",
      "apiVersion": "2022-07-02",
      "properties": {
        "encryptionSettingsCollection": {
          "enabled": false
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/snapshots@2022-07-02' = {
  properties: {
    encryptionSettingsCollection: {
      enabled: false
    }
  }
}

For Microsoft.Compute/virtualMachines:

Disabled encryption at host level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "securityProfile": {
          "encryptionAtHost": false
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    securityProfile: {
      encryptionAtHost: false
    }
  }
}

Disabled encryption for managed disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "dataDisks": [
            {
              "id": "myDiskId"
            }
          ]
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      dataDisks: [
        {
          name: 'myDisk'
        }
      ]
    }
  }
}

Disabled encryption for OS disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "osDisk": {
            "encryptionSettings": {
              "enabled": false
            }
          }
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      osDisk: {
        name: 'myDisk'
        encryptionSettings: {
          enabled: false
        }
      }
    }
  }
}

Disabled encryption for OS managed disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "osDisk": {
            "managedDisk": {
              "id": "myDiskId"
            }
          }
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      osDisk: {
        name: 'myDisk'
        managedDisk: {
          id: 'myDiskId'
        }
      }
    }
  }
}

For Microsoft.Compute/virtualMachineScaleSets:

Disabled encryption at host level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "securityProfile": {
            "encryptionAtHost": false
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      securityProfile: {
        encryptionAtHost: false
      }
    }
  }
}

Disabled encryption for data disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "storageProfile": {
            "dataDisks": [
              {
                "name": "myDataDisk"
              }
            ]
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      storageProfile: {
        dataDisks: [
          {
            name: 'myDataDisk'
          }
        ]
      }
    }
  }
}

Disabled encryption for OS disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "storageProfile": {
            "osDisk": {
              "name": "myOsDisk"
            }
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      storageProfile: {
        osDisk: {
          name: 'myOsDisk'
        }
      }
    }
  }
}

For Microsoft.ContainerService/managedClusters:

Disabled encryption at host and set the disk encryption set ID:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2023-03-02-preview",
      "properties": {
        "agentPoolProfiles": [
          {
            "enableEncryptionAtHost": false
          }
        ]
      }
    }
  ]
}

resource symbolicname 'Microsoft.ContainerService/managedClusters@2023-03-02-preview' = {
  properties: {
    agentPoolProfiles: [
      {
        enableEncryptionAtHost: false
      }
    ]
  }
}

For Microsoft.DataLakeStore/accounts:

Disabled encryption for Data Lake Store:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DataLakeStore/accounts",
      "apiVersion": "2016-11-01",
      "properties": {
        "encryptionState": "Disabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DataLakeStore/accounts@2016-11-01' = {
  properties: {
    encryptionState: 'Disabled'
  }
}

For Microsoft.DBforMySQL/servers:

Disabled infrastructure double encryption for MySQL server:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DBforMySQL/servers",
      "apiVersion": "2017-12-01",
      "properties": {
        "infrastructureEncryption": "Disabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DBforMySQL/servers@2017-12-01' = {
  properties: {
    infrastructureEncryption: 'Disabled'
  }
}

For Microsoft.DBforPostgreSQL/servers:

Disabled infrastructure double encryption for PostgreSQL server:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DBforPostgreSQL/servers",
      "apiVersion": "2017-12-01",
      "properties": {
        "infrastructureEncryption": "Disabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DBforPostgreSQL/servers@2017-12-01' = {
  properties: {
    infrastructureEncryption: 'Disabled'
  }
}

For Microsoft.DocumentDB/cassandraClusters/dataCenters:

Disabled encryption for a Cassandra Cluster datacenter’s managed disk and backup:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "cassandraClusters/example",
      "type": "Microsoft.DocumentDB/cassandraClusters/dataCenters",
      "apiVersion": "2023-04-15",
      "properties": {
        "diskCapacity": 4
      }
    }
  ]
}

resource symbolicname 'Microsoft.DocumentDB/cassandraClusters/dataCenters@2023-04-15' = {
  name: 'string'
  parent: parent
  properties: {
    diskCapacity: 4
  }
}

For Microsoft.HDInsight/clusters:

Disabled encryption for data disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.HDInsight/clusters",
      "apiVersion": "2021-06-01",
      "properties": {
        "computeProfile": {
          "roles": [
            {
              "encryptDataDisks": false
            }
          ]
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.HDInsight/clusters@2021-06-01' = {
  properties: {
    computeProfile: {
      roles: [
        {
          encryptDataDisks: false
        }
      ]
    }
  }
}

Disabled encryption for data disk at application level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "clusters/example",
      "type": "Microsoft.HDInsight/clusters/applications",
      "apiVersion": "2021-06-01",
      "properties": {
        "computeProfile": {
          "roles": [
            {
              "encryptDataDisks": false
            }
          ]
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.HDInsight/clusters/applications@2021-06-01' = {
  properties: {
    computeProfile: {
      roles: [
        {
          encryptDataDisks: false
        }
      ]
    }
  }
}

Disabled encryption for resource disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.HDInsight/clusters",
      "apiVersion": "2021-06-01",
      "properties": {
        "diskEncryptionProperties": {
          "encryptionAtHost": false
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.HDInsight/clusters@2021-06-01' = {
  properties: {
    diskEncryptionProperties: {
      encryptionAtHost: false
    }
  }
}

For Microsoft.Kusto/clusters:

Disabled encryption for disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Kusto/clusters",
      "apiVersion": "2022-12-29",
      "properties": {
        "enableDiskEncryption": false
      }
    }
  ]
}

resource symbolicname 'Microsoft.Kusto/clusters@2022-12-29' = {
  properties: {
    enableDiskEncryption: false
  }
}

For Microsoft.RecoveryServices/vaults:

Disabled encryption for disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.RecoveryServices/vaults",
      "apiVersion": "2023-01-01",
      "properties": {
        "encryption": {
          "infrastructureEncryption": "Disabled"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.RecoveryServices/vaults@2023-01-01' = {
  properties: {
    encryption: {
      infrastructureEncryption: 'Disabled'
    }
  }
}

Disabled encryption on infastructure for backup:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "vaults/example",
      "type": "Microsoft.RecoveryServices/vaults/backupEncryptionConfigs",
      "apiVersion": "2023-01-01",
      "properties": {
        "infrastructureEncryptionState": "Disabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.RecoveryServices/vaults/backupEncryptionConfigs@2023-01-01' = {
  properties: {
    encryptionAtRestType: '{CustomerManaged | MicrosoftManaged}'
    infrastructureEncryptionState: 'Disabled'
  }
}

For Microsoft.RedHatOpenShift/openShiftClusters:

Disabled disk encryption for master profile and worker profiles:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.RedHatOpenShift/openShiftClusters",
      "apiVersion": "2022-09-04",
      "properties": {
        "masterProfile": {
          "encryptionAtHost": "Disabled"
        },
        "workerProfiles": [
          {
            "encryptionAtHost": "Disabled"
          }
        ]
      }
    }
  ]
}

resource symbolicname 'Microsoft.RedHatOpenShift/openShiftClusters@2022-09-04' = {
  properties: {
    masterProfile: {
      encryptionAtHost: 'Disabled'
    }
    workerProfiles: [
      {
        encryptionAtHost: 'Disabled'
      }
    ]
  }
}

For Microsoft.SqlVirtualMachine/sqlVirtualMachines:

Disabled encryption for SQL Virtual Machine:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.SqlVirtualMachine/sqlVirtualMachines",
      "apiVersion": "2022-08-01-preview",
      "properties": {
        "autoBackupSettings": {
          "enableEncryption": false
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.SqlVirtualMachine/sqlVirtualMachines@2022-08-01-preview' = {
  properties: {
    autoBackupSettings: {
      enableEncryption: false
    }
  }
}

For Microsoft.Storage/storageAccounts:

Disabled enforcing of infrastructure encryption for double encryption of data:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "properties": {
        "encryption": {
          "requireInfrastructureEncryption": false
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  properties: {
    encryption: {
      requireInfrastructureEncryption: false
    }
  }
}

For Microsoft.Storage/storageAccounts/encryptionScopes:

Disabled enforcing of infrastructure encryption for double encryption of data at encryption scope level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "storageAccounts/example",
      "type": "Microsoft.Storage/storageAccounts/encryptionScopes",
      "apiVersion": "2022-09-01",
      "properties": {
        "requireInfrastructureEncryption": false
      }
    }
  ]
}

resource symbolicname 'Microsoft.Storage/storageAccounts/encryptionScopes@2022-09-01' = {
  properties: {
    requireInfrastructureEncryption: false
  }
}

Compliant Solution

For Microsoft.AzureArcData/sqlServerInstances/databases:

Enabled encryption on SQL service instance database:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "databases/example",
      "type": "Microsoft.AzureArcData/sqlServerInstances/databases",
      "apiVersion": "2023-03-15-preview",
      "properties": {
        "databaseOptions": {
          "isEncrypted": true
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.AzureArcData/sqlServerInstances/databases@2023-03-15-preview' = {
  properties: {
    databaseOptions: {
      isEncrypted: true
    }
  }
}

For Microsoft.Compute/disks:

Enabled encryption for managed disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/disks",
      "apiVersion": "2022-07-02",
      "properties": {
        "encryption": {
          "diskEncryptionSetId": "string",
          "type": "string"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/disks@2022-07-02' = {
  properties: {
    encryption: {
      diskEncryptionSetId: 'string'
      type: 'string'
    }
  }
}

Enabled encryption through setting encryptionSettingsCollection:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Compute/disks",
      "apiVersion": "2022-07-02",
      "properties": {
        "encryptionSettingsCollection": {
          "enabled": true,
          "encryptionSettings": [
            {
              "diskEncryptionKey": {
                "secretUrl": "string",
                "sourceVault": {
                  "id": "string"
                }
              }
            }
          ]
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/disks@2022-07-02' = {
  properties: {
    encryptionSettingsCollection: {
      enabled: true
      encryptionSettings: [
        {
          diskEncryptionKey: {
            secretUrl: 'string'
            sourceVault: {
              id: 'string'
            }
          }
        }
      ]
    }
  }
}

Enabled encryption through a security profile for an OS disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Compute/disks",
      "apiVersion": "2022-07-02",
      "properties": {
        "securityProfile": {
          "secureVMDiskEncryptionSetId": "string",
          "securityType": "{'ConfidentialVM_DiskEncryptedWithCustomerKey' | 'ConfidentialVM_DiskEncryptedWithPlatformKey' | 'ConfidentialVM_VMGuestStateOnlyEncryptedWithPlatformKey' | 'TrustedLaunch'}"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/disks@2022-07-02' = {
  properties: {
    securityProfile: {
      secureVMDiskEncryptionSetId: 'string'
      securityType: '{ConfidentialVM_DiskEncryptedWithCustomerKey | ConfidentialVM_DiskEncryptedWithPlatformKey | ConfidentialVM_VMGuestStateOnlyEncryptedWithPlatformKey | TrustedLaunch}'
    }
  }
}

For Microsoft.Compute/snapshots:

Enabled disk encryption for snapshot:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/snapshots",
      "apiVersion": "2022-07-02",
      "properties": {
        "encryption": {
          "diskEncryptionSetId": "string",
          "type": "{'EncryptionAtRestWithCustomerKey' | 'EncryptionAtRestWithPlatformAndCustomerKeys' | 'EncryptionAtRestWithPlatformKey'}"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/snapshots@2022-07-02' = {
  properties: {
    encryption: {
      diskEncryptionSetId: 'string'
      type: '{EncryptionAtRestWithCustomerKey | EncryptionAtRestWithPlatformAndCustomerKeys | EncryptionAtRestWithPlatformKey}'
    }
  }
}

Enabled disk encryption with settings collection:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/snapshots",
      "apiVersion": "2022-07-02",
      "properties": {
        "encryptionSettingsCollection": {
          "enabled": true,
          "encryptionSettings": [
            {
              "diskEncryptionKey": {
                "secretUrl": "",
                "sourceVault": {
                  "id": "string"
                }
              }
            }
          ],
          "encryptionSettingsVersion": "{'1.0' | '1.1'}"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/snapshots@2022-07-02' = {
  properties: {
    encryptionSettingsCollection: {
      enabled: true
      encryptionSettings: [
        {
          diskEncryptionKey: {
            secretUrl: ''
            sourceVault: {
              id: 'string'
            }
          }
        }
      ]
      encryptionSettingsVersion: '{1.0 | 1.1}'
    }
  }
}

Enabled disk encryption through security profile:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/snapshots",
      "apiVersion": "2022-07-02",
      "properties": {
        "securityProfile": {
          "secureVMDiskEncryptionSetId": "string",
          "securityType": "{'ConfidentialVM_DiskEncryptedWithCustomerKey' | 'ConfidentialVM_DiskEncryptedWithPlatformKey' | 'ConfidentialVM_VMGuestStateOnlyEncryptedWithPlatformKey' |'TrustedLaunch'}"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/snapshots@2022-07-02' = {
  properties: {
    securityProfile: {
      secureVMDiskEncryptionSetId: 'string'
      securityType: '{ConfidentialVM_DiskEncryptedWithCustomerKey | ConfidentialVM_DiskEncryptedWithPlatformKey | ConfidentialVM_VMGuestStateOnlyEncryptedWithPlatformKey | TrustedLaunch}'
    }
  }
}

For Microsoft.Compute/virtualMachines:

Enabled encryption at host level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "securityProfile": {
          "encryptionAtHost": true
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    securityProfile: {
      encryptionAtHost: true
    }
  }
}

Enabled encryption for managed disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "dataDisks": [
            {
              "id": "myDiskId",
              "managedDisk": {
                "diskEncryptionSet": {
                  "id": "string"
                }
              }
            }
          ]
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      dataDisks: [
        {
          name: 'myDisk'
          managedDisk: {
            diskEncryptionSet: {
              id: 'string'
            }
          }
        }
      ]
    }
  }
}

Enabled encryption for managed disk through security profile:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "dataDisks": [
            {
              "id": "myDiskId",
              "managedDisk": {
                "securityProfile": {
                  "diskEncryptionSet": {
                    "id": "string"
                  }
                }
              }
            }
          ]
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      dataDisks: [
        {
          name: 'myDisk'
          managedDisk: {
            securityProfile: {
              diskEncryptionSet: {
                id: 'string'
              }
            }
          }
        }
      ]
    }
  }
}

Enabled encryption for OS disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "osDisk": {
            "encryptionSettings": {
              "enabled": true,
              "diskEncryptionKey": {
                "secretUrl": "string",
                "sourceVault": {
                  "id": "string"
                }
              }
            }
          }
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      osDisk: {
        name: 'myDisk'
        encryptionSettings: {
          enabled: true
          diskEncryptionKey: {
            secretUrl: 'string'
            sourceVault: {
              id: 'string'
            }
          }
        }
      }
    }
  }
}

Enabled encryption for OS managed disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "osDisk": {
            "managedDisk": {
              "id": "myDiskId",
              "diskEncryptionSet": {
                "id": "string"
              }
            }
          }
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      osDisk: {
        name: 'myDisk'
        managedDisk: {
          id: 'myDiskId'
          diskEncryptionSet: {
            id: 'string'
          }
        }
      }
    }
  }
}

Enabled encryption for OS managed disk through security profile:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2022-11-01",
      "properties": {
        "storageProfile": {
          "osDisk": {
            "managedDisk": {
              "securityProfile": {
                "diskEncryptionSet": {
                  "id": "string"
                }
              }
            }
          }
        }
      }
    }
  ]
}

resource myName 'Microsoft.Compute/virtualMachines@2022-11-01' = {
  properties: {
    storageProfile: {
      osDisk: {
        name: 'myDisk'
        managedDisk: {
          id: 'myDiskId'
          securityProfile: {
            diskEncryptionSet: {
              id: 'string'
            }
          }
        }
      }
    }
  }
}

For Microsoft.Compute/virtualMachineScaleSets:

Enabled encryption at host level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "securityProfile": {
            "encryptionAtHost": true
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      securityProfile: {
        encryptionAtHost: true
      }
    }
  }
}

Enabled encryption for data disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "storageProfile": {
            "dataDisks": [
              {
                "name": "myDataDisk",
                "managedDisk": {
                  "diskEncryptionSet": {
                    "id": "string"
                  }
                }
              }
            ]
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      storageProfile: {
        dataDisks: [
          {
            name: 'myDataDisk'
            managedDisk: {
              diskEncryptionSet: {
                id: 'string'
              }
            }
          }
        ]
      }
    }
  }
}

Enabled encryption for data disk through security profile:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "storageProfile": {
            "dataDisks": [
              {
                "name": "myDataDisk",
                "managedDisk": {
                  "securityProfile": {
                    "diskEncryptionSet": {
                      "id": "string"
                    }
                  }
                }
              }
            ]
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      storageProfile: {
        dataDisks: [
          {
            name: 'myDataDisk'
            managedDisk: {
              securityProfile: {
                diskEncryptionSet: {
                  id: 'string'
                }
              }
            }
          }
        ]
      }
    }
  }
}

Enabled encryption for OS disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "storageProfile": {
            "osDisk": {
              "name": "myOsDisk",
              "managedDisk": {
                "diskEncryptionSet": {
                  "id": "string"
                }
              }
            }
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      storageProfile: {
        osDisk: {
          name: 'myOsDisk'
          managedDisk: {
            diskEncryptionSet: {
              id: 'string'
            }
          }
        }
      }
    }
  }
}

Enabled encryption for OS disk through security profile:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "apiVersion": "2022-11-01",
      "properties": {
        "virtualMachineProfile": {
          "storageProfile": {
            "osDisk": {
              "name": "myOsDisk",
              "managedDisk": {
                "securityProfile": {
                  "diskEncryptionSet": {
                    "id": "string"
                  }
                }
              }
            }
          }
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets@2022-11-01' = {
  properties: {
    virtualMachineProfile: {
      storageProfile: {
        osDisk: {
          name: 'myOsDisk'
          managedDisk: {
            securityProfile: {
              diskEncryptionSet: {
                id: 'string'
              }
            }
          }
        }
      }
    }
  }
}

For Microsoft.ContainerService/managedClusters:

Enabled encryption at host and set the disk encryption set ID:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2023-03-02-preview",
      "properties": {
        "agentPoolProfiles": [
          {
            "enableEncryptionAtHost": true
          }
        ],
        "diskEncryptionSetID": "string"
      }
    }
  ]
}

resource symbolicname 'Microsoft.ContainerService/managedClusters@2023-03-02-preview' = {
  properties: {
    agentPoolProfiles: [
      {
        enableEncryptionAtHost: true
      }
    ]
    diskEncryptionSetID: 'string'
  }
}

For Microsoft.DataLakeStore/accounts:

Enabled encryption for Data Lake Store:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DataLakeStore/accounts",
      "apiVersion": "2016-11-01",
      "properties": {
        "encryptionState": "Enabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DataLakeStore/accounts@2016-11-01' = {
  properties: {
    encryptionState: 'Enabled'
  }
}

For Microsoft.DBforMySQL/servers:

Enabled infrastructure double encryption for MySQL server:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DBforMySQL/servers",
      "apiVersion": "2017-12-01",
      "properties": {
        "infrastructureEncryption": "Enabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DBforMySQL/servers@2017-12-01' = {
  properties: {
    infrastructureEncryption: 'Enabled'
  }
}

For Microsoft.DBforPostgreSQL/servers:

Enabled infrastructure double encryption for PostgreSQL server:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DBforPostgreSQL/servers",
      "apiVersion": "2017-12-01",
      "properties": {
        "infrastructureEncryption": "Enabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DBforPostgreSQL/servers@2017-12-01' = {
  properties: {
    infrastructureEncryption: 'Enabled'
  }
}

For Microsoft.DocumentDB/cassandraClusters/dataCenters:

Enabled encryption for a Cassandra Cluster datacenter’s managed disk and backup:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "cassandraClusters/example",
      "type": "Microsoft.DocumentDB/cassandraClusters/dataCenters",
      "apiVersion": "2023-04-15",
      "properties": {
        "diskCapacity": 4,
        "backupStorageCustomerKeyUri": "string",
        "managedDiskCustomerKeyUri": "string"
      }
    }
  ]
}

resource symbolicname 'Microsoft.DocumentDB/cassandraClusters/dataCenters@2023-04-15' = {
  name: 'string'
  parent: parent
  properties: {
    diskCapacity: 4
    backupStorageCustomerKeyUri: 'string'
    managedDiskCustomerKeyUri: 'string'
  }
}

For Microsoft.HDInsight/clusters:

Enabled encryption for data disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.HDInsight/clusters",
      "apiVersion": "2021-06-01",
      "properties": {
        "computeProfile": {
          "roles": [
            {
              "encryptDataDisks": true
            }
          ]
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.HDInsight/clusters@2021-06-01' = {
  properties: {
    computeProfile: {
      roles: [
        {
          encryptDataDisks: true
        }
      ]
    }
  }
}

Enabled encryption for data disk at application level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "clusters/example",
      "type": "Microsoft.HDInsight/clusters/applications",
      "apiVersion": "2021-06-01",
      "properties": {
        "computeProfile": {
          "roles": [
            {
              "encryptDataDisks": true
            }
          ]
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.HDInsight/clusters/applications@2021-06-01' = {
  properties: {
    computeProfile: {
      roles: [
        {
          encryptDataDisks: true
        }
      ]
    }
  }
}

Enabled encryption for resource disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.HDInsight/clusters",
      "apiVersion": "2021-06-01",
      "properties": {
        "diskEncryptionProperties": {
          "encryptionAtHost": true
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.HDInsight/clusters@2021-06-01' = {
  properties: {
    diskEncryptionProperties: {
      encryptionAtHost: true
    }
  }
}

For Microsoft.Kusto/clusters:

Enabled encryption for disk:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Kusto/clusters",
      "apiVersion": "2022-12-29",
      "properties": {
        "enableDiskEncryption": true
      }
    }
  ]
}

resource symbolicname 'Microsoft.Kusto/clusters@2022-12-29' = {
  properties: {
    enableDiskEncryption: true
  }
}

For Microsoft.RecoveryServices/vaults:

Enabled encryption on infrastructure:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.RecoveryServices/vaults",
      "apiVersion": "2023-01-01",
      "properties": {
        "encryption": {
          "infrastructureEncryption": "Enabled"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.RecoveryServices/vaults@2023-01-01' = {
  properties: {
    encryption: {
      infrastructureEncryption: 'Enabled'
    }
  }
}

Enabled encryption on infastructure for backup:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "vaults/example",
      "type": "Microsoft.RecoveryServices/vaults/backupEncryptionConfigs",
      "apiVersion": "2023-01-01",
      "properties": {
        "encryptionAtRestType": "{'CustomerManaged' | 'MicrosoftManaged'}",
        "infrastructureEncryptionState": "Enabled"
      }
    }
  ]
}

resource symbolicname 'Microsoft.RecoveryServices/vaults/backupEncryptionConfigs@2023-01-01' = {
  properties: {
    encryptionAtRestType: '{CustomerManaged | MicrosoftManaged}'
    infrastructureEncryptionState: 'Enabled'
  }
}

For Microsoft.RedHatOpenShift/openShiftClusters:

Enabled disk encryption for master profile and worker profiles:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.RedHatOpenShift/openShiftClusters",
      "apiVersion": "2022-09-04",
      "properties": {
        "masterProfile": {
          "diskEncryptionSetId": "string",
          "encryptionAtHost": "Enabled"
        },
        "workerProfiles": [
          {
            "diskEncryptionSetId": "string",
            "encryptionAtHost": "Enabled"
          }
        ]
      }
    }
  ]
}

resource symbolicname 'Microsoft.RedHatOpenShift/openShiftClusters@2022-09-04' = {
  properties: {
    masterProfile: {
      diskEncryptionSetId: 'string'
      encryptionAtHost: 'Enabled'
    }
    workerProfiles: [
      {
        diskEncryptionSetId: 'string'
        encryptionAtHost: 'Enabled'
      }
    ]
  }
}

For Microsoft.SqlVirtualMachine/sqlVirtualMachines:

Enabled encryption for SQL Virtual Machine:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.SqlVirtualMachine/sqlVirtualMachines",
      "apiVersion": "2022-08-01-preview",
      "properties": {
        "autoBackupSettings": {
          "enableEncryption": true,
          "password": "string"
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.SqlVirtualMachine/sqlVirtualMachines@2022-08-01-preview' = {
  properties: {
    autoBackupSettings: {
      enableEncryption: true
      password: 'string'
    }
  }
}

For Microsoft.Storage/storageAccounts:

Enabled enforcing of infrastructure encryption for double encryption of data:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "properties": {
        "encryption": {
          "requireInfrastructureEncryption": true
        }
      }
    }
  ]
}

resource symbolicname 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  properties: {
    encryption: {
      requireInfrastructureEncryption: true
    }
  }
}

For Microsoft.Storage/storageAccounts/encryptionScopes:

Enabled enforcing of infrastructure encryption for double encryption of data at encryption scope level:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "storageAccounts/example",
      "type": "Microsoft.Storage/storageAccounts/encryptionScopes",
      "apiVersion": "2022-09-01",
      "properties": {
        "requireInfrastructureEncryption": true
      }
    }
  ]
}

resource symbolicname 'Microsoft.Storage/storageAccounts/encryptionScopes@2022-09-01' = {
  properties: {
    requireInfrastructureEncryption: true
  }
}

See

• Data encryption in Amazon EFS
• CWE - CWE-311 - Missing Encryption of Sensitive Data
• Encryption in Azure Backup
• Security in Azure Database for MySQL
• Security in Azure Database for PostgreSQL
• Infrastructure double encryption of data

Why is this an issue?

Cloud platforms such as Azure support virtual firewalls that can be used to restrict access to services by controlling inbound and outbound traffic.
Any firewall rule allowing traffic from all IP addresses to standard network ports on which administration services traditionally listen, such as 22 for SSH, can expose these services to exploits and unauthorized access.

What is the potential impact?

Like any other service, administration services can contain vulnerabilities. Administration services run with elevated privileges and thus a vulnerability could have a high impact on the system.

Additionally, credentials might be leaked through phishing or similar techniques. Attackers who are able to reach the services could use the credentials to log in to the system.

How to fix it

It is recommended to restrict access to remote administration services to only trusted IP addresses. In practice, trusted IP addresses are those held by system administrators or those of bastion-like servers.

Code examples

Noncompliant code example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "networkSecurityGroups/example",
      "type": "Microsoft.Network/networkSecurityGroups/securityRules",
      "apiVersion": "2022-11-01",
      "properties": {
        "protocol": "*",
        "destinationPortRange": "*",
        "sourceAddressPrefix": "*",
        "access": "Allow",
        "direction": "Inbound"
      }
    }
  ]
}

resource securityRules 'Microsoft.Network/networkSecurityGroups/securityRules@2022-11-01' = {
  name: 'securityRules'
  properties: {
    direction: 'Inbound'
    access: 'Allow'
    protocol: '*'
    destinationPortRange: '*'
    sourceAddressPrefix: '*'
  }
}

Compliant solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "networkSecurityGroups/example",
      "type": "Microsoft.Network/networkSecurityGroups/securityRules",
      "apiVersion": "2022-11-01",
      "properties": {
          "protocol": "*",
          "destinationPortRange": "22",
          "sourceAddressPrefix": "10.0.0.0/24",
          "access": "Allow",
          "direction": "Inbound"
      }
    }
  ]
}

resource securityRules 'Microsoft.Network/networkSecurityGroups/securityRules@2022-11-01' = {
  name: 'securityRules'
  properties: {
    direction: 'Inbound'
    access: 'Allow'
    protocol: '*'
    destinationPortRange: '22'
    sourceAddressPrefix: '10.0.0.0/24'
  }
}

Resources

Documentation

• AWS Documentation - Security groups for your VPC
• Azure Documentation - Network security groups
• GCP Documentation - Firewalls

Standards

• CWE - CWE-284 - Improper Access Control

Reducing the backup retention duration can reduce an organization’s ability to re-establish service in case of a security incident.

Data backups allow to overcome corruption or unavailability of data by recovering as efficiently as possible from a security incident.

Backup retention duration, coverage, and backup locations are essential criteria regarding functional continuity.

Ask Yourself Whether

• This component is essential for the information system infrastructure.
• This component is essential for mission-critical functions.
• Compliance policies require this component to be backed up for a specific amount of time.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Increase the backup retention period to an amount of time sufficient enough to be able to restore service in case of an incident.

Sensitive Code Example

For Azure App Service:

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: 'webApp'
}

resource backup 'config@2022-03-01' = {
  name: 'backup'
  parent: webApp
  properties: {
    backupSchedule: {
      frequencyInterval: 1
      frequencyUnit: 'Day'
      keepAtLeastOneBackup: true
      retentionPeriodInDays: 2  // Sensitive
    }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2022-03-01",
      "name": "webApp",
    },
    {
      "type": "Microsoft.Web/sites/config",
      "apiVersion": "2022-03-01",
      "name": "webApp/backup",
      "properties": {
        "backupSchedule": {
          "frequencyInterval": 1,
          "frequencyUnit": "Day",
          "keepAtLeastOneBackup": true,
          "retentionPeriodInDays": 2
        }
      },
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', 'webApp')]"
      ]
    }
  ]
}

For Azure Cosmos DB accounts:

resource cosmosDb 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    properties: {
        backupPolicy: {
            type: 'Periodic'
            periodicModeProperties: {
                backupIntervalInMinutes: 1440
                backupRetentionIntervalInHours: 8  // Sensitive
            }
        }
    }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DocumentDB/databaseAccounts",
      "apiVersion": "2023-04-15",
      "properties": {
        "backupPolicy": {
          "type": "Periodic",
          "periodicModeProperties": {
            "backupIntervalInMinutes": 1440,
            "backupRetentionIntervalInHours": 8
          }
        }
      }
    }
  ]
}

For Azure Backup vault policies:

resource vault 'Microsoft.RecoveryServices/vaults@2023-01-01' = {
    name: 'testVault'

    resource backupPolicy 'backupPolicies@2023-01-01' = {
        name: 'backupPolicy'
        properties: {
            backupManagementType: 'AzureSql'
            retentionPolicy: {
                retentionPolicyType: 'SimpleRetentionPolicy'
                retentionDuration: {
                    count: 2  // Sensitive
                    durationType: 'Days'
                }
            }
        }
    }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.RecoveryServices/vaults",
      "apiVersion": "2023-01-01",
      "name": "testVault",
      "resources": [
        {
          "type": "backupPolicies",
          "apiVersion": "2023-01-01",
          "name": "testVault/backupPolicy",
          "properties": {
            "backupManagementType": "AzureSql",
            "retentionPolicy": {
              "retentionPolicyType": "SimpleRetentionPolicy",
              "retentionDuration": {
                "count": 2,
                "durationType": "Days"
              }
            }
          }
        }
      ]
    }
  ]
}

Compliant Solution

For Azure App Service:

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: 'webApp'
}

resource backup 'config@2022-03-01' = {
  name: 'backup'
  parent: webApp
  properties: {
    backupSchedule: {
      frequencyInterval: 1
      frequencyUnit: 'Day'
      keepAtLeastOneBackup: true
      retentionPeriodInDays: 8
    }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2022-03-01",
      "name": "webApp",
    },
    {
      "type": "Microsoft.Web/sites/config",
      "apiVersion": "2022-03-01",
      "name": "webApp/backup",
      "properties": {
        "backupSchedule": {
          "frequencyInterval": 1,
          "frequencyUnit": "Day",
          "keepAtLeastOneBackup": true,
          "retentionPeriodInDays": 30
        }
      },
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', 'webApp')]"
      ]
    }
  ]
}

For Azure Cosmos DB accounts:

resource cosmosDb 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    properties: {
        backupPolicy: {
            type: 'Periodic'
            periodicModeProperties: {
                backupIntervalInMinutes: 1440
                backupRetentionIntervalInHours: 192
            }
        }
    }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.DocumentDB/databaseAccounts",
      "apiVersion": "2023-04-15",
      "properties": {
        "backupPolicy": {
          "type": "Periodic",
          "periodicModeProperties": {
            "backupIntervalInMinutes": 1440,
            "backupRetentionIntervalInHours": 720
          }
        }
      }
    }
  ]
}

For Azure Backup vault policies:

resource vault 'Microsoft.RecoveryServices/vaults@2023-01-01' = {
    name: 'testVault'

    resource backupPolicy 'backupPolicies@2023-01-01' = {
        name: 'backupPolicy'
        properties: {
            backupManagementType: 'AzureSql'
            retentionPolicy: {
                retentionPolicyType: 'SimpleRetentionPolicy'
                retentionDuration: {
                    count: 8
                    durationType: 'Days'
                }
            }
        }
    }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.RecoveryServices/vaults",
      "apiVersion": "2023-01-01",
      "name": "testVault",
      "resources": [
        {
          "type": "backupPolicies",
          "apiVersion": "2023-01-01",
          "name": "testVault/backupPolicy",
          "properties": {
            "backupManagementType": "AzureSql",
            "retentionPolicy": {
              "retentionPolicyType": "SimpleRetentionPolicy",
              "retentionDuration": {
                "count": 30,
                "durationType": "Days"
              }
            }
          }
        }
      ]
    }
  ]
}

Enabling Azure resource-specific admin accounts can reduce an organization’s ability to protect itself against account or service account thefts.

Full Administrator permissions fail to correctly separate duties and create potentially critical attack vectors on the impacted resources.

In case of abuse of elevated permissions, both the data on which impacted resources operate and their access traceability are at risk.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• Compliance policies require this resource to disable its administrative accounts or permissions.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Disable the administrative accounts or permissions in this Azure resource.

Sensitive Code Example

For Azure Batch Pools:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Batch/batchAccounts/pools",
      "apiVersion": "2022-10-01",
      "properties": {
        "startTask": {
          "userIdentity": {
            "autoUser": {
              "elevationLevel": "Admin"
            }
          }
        }
      }
    }
  ]
}

resource AdminBatchPool 'Microsoft.Batch/batchAccounts/pools@2022-10-01' = {
  properties: {
    startTask: {
      userIdentity: {
        autoUser: {
          elevationLevel: 'Admin' // Sensitive
        }
      }
    }
  }
}

For Azure Container Registries:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.ContainerRegistry/registries",
      "apiVersion": "2023-01-01-preview",
      "properties": {
        "adminUserEnabled": true
      }
    }
  ]
}

resource acrAdminUserDisabled 'Microsoft.ContainerRegistry/registries@2021-09-01' = {
  properties: {
    adminUserEnabled: true // Sensitive
  }
}

Compliant Solution

For Azure Batch Pools:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Batch/batchAccounts/pools",
      "apiVersion": "2022-10-01",
      "properties": {
        "startTask": {
          "userIdentity": {
            "autoUser": {
              "elevationLevel": "NonAdmin"
            }
          }
        }
      }
    }
  ]
}

resource AdminBatchPool 'Microsoft.Batch/batchAccounts/pools@2022-10-01' = {
  properties: {
    startTask: {
      userIdentity: {
        autoUser: {
          elevationLevel: 'NonAdmin'
        }
      }
    }
  }
}

For Azure Container Registries:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.ContainerRegistry/registries",
      "apiVersion": "2023-01-01-preview",
      "properties": {
        "adminUserEnabled": false
      }
    }
  ]
}

resource acrAdminUserDisabled 'Microsoft.ContainerRegistry/registries@2021-09-01' = {
  properties: {
    adminUserEnabled: false
  }
}

See

• CWE - CWE-284 - Improper Access Control

Allowing anonymous access can reduce an organization’s ability to protect itself against attacks on its Azure resources.

Security incidents may include disrupting critical functions, data theft, and additional Azure subscription costs due to resource overload.

Using authentication coupled with fine-grained authorizations helps bring defense-in-depth and bring traceability to investigators of security incidents.

Depending on the affected Azure resource, multiple authentication choices are possible: Active Directory Authentication, OpenID implementations (Google, Microsoft, etc.) or native Azure mechanisms.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• This Azure resource stores or processes sensitive data.
• Compliance policies require access to this resource to be authenticated.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Enable authentication in this Azure resource, and disable anonymous access.

If only Basic Authentication is available, enable it.

Sensitive Code Example

For App Service:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2022-03-01",
            "name": "example"
        }
    ]
}

resource appService 'Microsoft.Web/sites@2022-09-01' = {
    name: 'example'
    // Sensitive: no authentication defined
}

For API Management:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.ApiManagement/service",
            "apiVersion": "2022-09-01-preview",
            "name": "example"
        }
    ]
}

resource apiManagementService 'Microsoft.ApiManagement/service@2022-09-01-preview' = {
    name: 'example'
    // Sensitive: no portal authentication defined

    resource apis 'apis@2022-09-01-preview' = {
        name: 'exampleApi'
        properties: {
            path: '/test'
            // Sensitive: no API authentication defined
        }
    }
}

For Data Factory Linked Services:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.DataFactory/factories/linkedservices",
            "apiVersion": "2018-06-01",
            "name": "example",
            "properties": {
                "type": "Web",
                "typeProperties": {
                    "authenticationType": "Anonymous"
                }
            }
        }
    ]
}

resource linkedService 'Microsoft.DataFactory/factories/linkedservices@2018-06-01' = {
    name: 'example'
    properties: {
        type: 'Web'
        typeProperties: {
            authenticationType: 'Anonymous' // Sensitive
        }
    }
}

For Storage Accounts and Storage Containers:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2022-09-01",
            "name": "example",
            "properties": {
                "allowBlobPublicAccess": true
            }
        }
    ]
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
    name: 'example'
    properties: {
        allowBlobPublicAccess: true // Sensitive
    }
}

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2022-09-01",
            "name": "example",
            "resources": [
                {
                    "type": "blobServices/containers",
                    "apiVersion": "2022-09-01",
                    "name": "blobContainerExample",
                    "properties": {
                        "publicAccess": "Blob"
                    }
                }
            ]
        }
    ]
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
    name: 'example'

    resource blobService 'blobServices@2022-09-01' = {
        name: 'default'

        resource containers 'containers@2022-09-01' = {
            name: 'exampleContainer'
            properties: {
                publicAccess: 'Blob' // Sensitive
            }
        }
    }
}

For Redis Caches:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Cache/redis",
            "apiVersion": "2022-06-01",
            "name": "example",
            "properties": {
                "redisConfiguration": {
                    "authnotrequired": "true"
                }
            }
        }
    ]
}

resource redisCache 'Microsoft.Cache/redis@2023-04-01' = {
    name: 'example'
    location: location
    properties: {
        redisConfiguration: {
            authnotrequired: 'true' // Sensitive
        }
    }
}

Compliant Solution

For App Services and equivalent:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2022-03-01",
            "name": "example",
            "resources": [
                {
                    "type": "config",
                    "apiVersion": "2022-03-01",
                    "name": "authsettingsV2",
                    "properties": {
                        "globalValidation": {
                            "requireAuthentication": true,
                            "unauthenticatedClientAction": "RedirectToLoginPage"
                        }
                    }
                }
            ]
        }
    ]
}

resource appService 'Microsoft.Web/sites@2022-09-01' = {
    name: 'example'

    resource authSettings 'config@2022-09-01' = { // Compliant
        name: 'authsettingsV2'
        properties: {
            globalValidation: {
                requireAuthentication: true
                unauthenticatedClientAction: 'AllowAnonymous'
            }
            platform: {
                enabled: true
            }
        }
    }
}

For API Management:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.ApiManagement/service",
            "apiVersion": "2022-09-01-preview",
            "name": "example",
            "resources": [
                {
                    "type": "portalsettings",
                    "apiVersion": "2022-09-01-preview",
                    "name": "signin",
                    "properties": {
                        "enabled": true
                    }
                },
                {
                    "type": "apis",
                    "apiVersion": "2022-09-01-preview",
                    "name": "exampleApi",
                    "properties": {
                        "authenticationSettings": {
                            "openid": {
                                "bearerTokenSendingMethods": ["authorizationHeader"],
                                "openidProviderId": "<an OpenID provider ID>"
                            }
                        }
                    }
                }
            ]
        }
    ]
}

resource apiManagementService 'Microsoft.ApiManagement/service@2022-09-01-preview' = {
    name: 'example'

    resource portalSettings 'portalsettings@2022-09-01-preview' = {
        name: 'signin'
        properties: {
            enabled: true // Compliant: Sign-in is enabled for portal access
        }
    }

    resource apis 'apis@2022-09-01-preview' = {
        name: 'exampleApi'
        properties: {
            path: '/test'
            authenticationSettings: { // Compliant: API has authentication enabled
                openid: {
                    bearerTokenSendingMethods: ['authorizationHeader']
                    openidProviderId: '<an OpenID provider ID>'
                }
            }
        }
    }
}

For Data Factory Linked Services:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.DataFactory/factories/linkedservices",
            "apiVersion": "2018-06-01",
            "name": "example",
            "properties": {
                "type": "Web",
                "typeProperties": {
                    "authenticationType": "Basic"
                }
            }
        }
    ]
}

@secure()
@description('The password for authentication')
param password string

resource linkedService 'Microsoft.DataFactory/factories/linkedservices@2018-06-01' = {
    name: 'example'
    properties: {
        type: 'Web'
        typeProperties: {
            authenticationType: 'Basic' // Compliant
            username: 'test'
            password: {
                type: 'SecureString'
                value: password
            }
        }
    }
}

For Storage Accounts:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2022-09-01",
            "name": "example",
            "properties": {
                "allowBlobPublicAccess": false
            }
        }
    ]
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'example'
  properties: {
    allowBlobPublicAccess: false // Compliant
  }
}

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2022-09-01",
            "name": "example",
            "resources": [
                {
                    "type": "blobServices/containers",
                    "apiVersion": "2022-09-01",
                    "name": "blobContainerExample",
                    "properties": {
                        "publicAccess": "None"
                    }
                }
            ]
        }
    ]
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
    name: 'example'

    resource blobService 'blobServices@2022-09-01' = {
        name: 'default'

        resource containers 'containers@2022-09-01' = {
            name: 'exampleContainer'
            properties: {
                publicAccess: 'None' // Compliant
            }
        }
    }
}

For Redis Caches:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Cache/redis",
            "apiVersion": "2022-06-01",
            "name": "example",
            "properties": {
                "redisConfiguration": {}
            }
        }
    ]
}

resource redisCache 'Microsoft.Cache/redis@2023-04-01' = {
    name: 'example'
    location: location
    properties: {
        redisConfiguration: {
            // Compliant: authentication is enabled by default
        }
    }
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Azure Resource Manager offers built-in roles that can be assigned to users, groups, or service principals. Some of these roles should be carefully assigned as they grant sensitive permissions like the ability to reset passwords for all users.

An Azure account that fails to limit the use of such roles has a higher risk of being breached by a compromised owner.

This rule raises an issue when one of the following roles is assigned:

• Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c)
• Owner (8e3af657-a8ff-443c-a75c-2fe8c4bcb635)
• User Access Administrator (18d7d88d-d35e-4fb5-a5c3-7773c20a72d9)

Ask Yourself Whether

• The user, group, or service principal doesn’t use the entirety of this extensive set of permissions to operate on a day-to-day basis.
• It is possible to follow the Separation of Duties principle and split permissions between multiple users, but it’s not enforced.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

• Limit the assignment of Owner roles to less than 3 people or service principals.
• Apply the least privilege principle by choosing a role with a limited set of permissions.
• If no built-in role meets your needs, create a custom role with as few permissions as possible.

Sensitive Code Example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2022-04-01",
      "properties": {
        "description": "Assign the contributor role",
        "principalId": "string",
        "principalType": "ServicePrincipal",
        "roleDefinitionId": "[resourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c')]"
      }
    }
  ]
}

resource symbolicname 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: tenant()
  properties: {
    description: 'Assign the contributor role'
    principalId: 'string'
    principalType: 'ServicePrincipal'
    roleDefinitionId: resourceId('Microsoft.Authorization/roleAssignments', 'b24988ac-6180-42a0-ab88-20f7382dd24c') // Sensitive
  }
}

Compliant Solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2022-04-01",
      "properties": {
        "description": "Assign the reader role",
        "principalId": "string",
        "principalType": "ServicePrincipal",
        "roleDefinitionId": "[resourceId('Microsoft.Authorization/roleDefinitions', 'acdd72a7-3385-48ef-bd42-f606fba81ae7')]"
      }
    }
  ]
}

resource symbolicname 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: tenant()
  properties: {
    description: 'Assign the reader role'
    principalId: 'string'
    principalType: 'ServicePrincipal'
    roleDefinitionId: resourceId('Microsoft.Authorization/roleAssignments', 'acdd72a7-3385-48ef-bd42-f606fba81ae7')
  }
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• Azure Documentation - Azure built-in roles
• Azure Documentation - Best practices for Azure RBAC

Defining a custom role at the Subscription or Management group scope that allows all actions will give it the same capabilities as the built-in Owner role.

Why is this an issue?

In Azure, the Owner role of a Subscription or a Management group provides entities it is assigned to with the maximum level of privileges. The Owner role allows managing all resources and assigning any role to other entities.

Because it is a powerful entitlement, it should be granted to as few users as possible.

When a custom role has the same level of permissions as the Owner one, there are greater chances that high privileges are granted to too many users.

What is the potential impact?

Custom roles that provide the same level of permissions as Owner might indicate a configuration issue. Any entity assigned with it can perform any action on the Subscription or Management group, including changing roles and permissions.

If the affected role is unexpectedly assigned to users, they can compromise the affected scope. They can do so in the long term by assigning dangerous roles to other users or entities.

Depending on the scope to which the role is assignable, the exact impact of a successful exploitation may vary. It generally ranges from data compromise to the takeover of the cloud infrastructure.

Infrastructure takeover

By obtaining the right role, an attacker can gain control over part or all of the Azure infrastructure. They can modify DNS settings, redirect traffic, or launch malicious instances that can be used for various nefarious activities, including launching DDoS attacks, hosting phishing websites, or distributing malware. Malicious instances may also be used for resource-intensive tasks such as cryptocurrency mining.

This can result in legal liability, but also increased costs, degraded performance, and potential service disruptions.

Furthermore, corporate Azure infrastructures are often connected to other services and to the internal networks of the organization. Because of this, cloud infrastructure is often used by attackers as a gateway to other assets. Attackers can leverage this gateway to gain access to more services, to compromise more business-critical data, and to cause more damage to the overall infrastructure.

Compromise of sensitive data

If the affected service is used to store or process personally identifiable information or other sensitive data, attackers with the correct role could be able to access it. Depending on the type of data that is compromised, it could lead to privacy violations, identity theft, financial loss, or other negative outcomes.

In most cases, a company suffering a sensitive data compromise will face a reputational loss when the security issue is publicly disclosed.

Financial loss

Financial losses can occur when a malicious user is able to use a paid third-party-provided service. Each users assigned with a bad role will be able to use it without limit to use the third party service to their own need, including in a way that was not expected.

This additional use will lead to added costs with the Azure service provider.

Moreover, when rate or volume limiting is set up on the provider side, this additional use can prevent the regular operation of the affected environment. This might result in a partial denial of service for all legitimate users.

How to fix it

To reduce the risk of intrusion of a compromised owner, it is recommended to limit the number of subscription owners.

Code examples

Noncompliant code example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleDefinitions",
      "apiVersion": "2022-04-01",
      "properties": {
        "permissions": [
          {
            "actions": ["*"],
            "notActions": []
          }
        ],
        "assignableScopes": [
          "[subscription().id]"
        ]
      }
    }
  ]
}

targetScope = 'managementGroup'

resource roleDef 'Microsoft.Authorization/roleDefinitions@2022-04-01' = { // Sensitive
  properties: {
    permissions: [
      {
        actions: ['*']
        notActions: []
      }
    ]

    assignableScopes: [
      managementGroup().id
    ]
  }
}

Compliant solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleDefinitions",
      "apiVersion": "2022-04-01",
      "properties": {
        "permissions": [
          {
            "actions": ["Microsoft.Compute/*"],
            "notActions": []
          }
        ],
        "assignableScopes": [
          "[subscription().id]"
        ]
      }
    }
  ]
}

targetScope = 'managementGroup'

resource roleDef 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
  properties: {
    permissions: [
      {
        actions: ['Microsoft.Compute/*']
        notActions: []
      }
    ]

    assignableScopes: [
      managementGroup().id
    ]
  }
}

Going the extra mile

Here is a list of recommendations that can be followed regarding good usage of roles:

• Apply the least privilege principle by creating a custom role with as few permissions as possible.
• As custom roles can be updated, gradually add atomic permissions when required.
• Limit the assignable scopes of the custom role to a set of Resources or Resource Groups.
• When necessary, use the built-in Owner role instead of a custom role granting subscription owner capabilities.
• Limit the assignments of Owner roles to less than three people or service principals.

Resources

Documentation

• Azure Documentation - Azure custom roles
• Azure Documentation - Best practices for Azure RBAC

Standards

• CWE - CWE-266 - Incorrect Privilege Assignment

Azure RBAC roles can be assigned to users, groups, or service principals. A role assignment grants permissions on a predefined set of resources called "scope".

The widest scopes a role can be assigned to are:

• Subscription: a role assigned with this scope grants access to all resources of this Subscription.
• Management Group: a scope assigned with this scope grants access to all resources of all the Subscriptions in this Management Group.

In case of security incidents involving a compromised identity (user, group, or service principal), limiting its role assignment to the narrowest scope possible helps separate duties and limits what resources are at risk.

Ask Yourself Whether

• The user, group, or service principal doesn’t use the entirety of the resources in the scope to operate on a day-to-day basis.
• It is possible to follow the Separation of Duties principle and split the scope into multiple role assignments with a narrower scope.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

• Limit the scope of the role assignment to a Resource or Resource Group.
• Apply the least privilege principle by assigning roles granting as few permissions as possible.

Sensitive Code Example

targetScope = 'subscription' // Sensitive

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(subscription().id, 'exampleRoleAssignment')
}

{
  "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2022-04-01",
      "name": "[guid(subscription().id, 'exampleRoleAssignment')]"
    }
  ]
}

Compliant Solution

targetScope = 'resourceGroup'

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, 'exampleRoleAssignment')
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2022-04-01",
      "name": "[guid(resourceGroup().id, 'exampleRoleAssignment')]"
    }
  ]
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• Azure Documentation - Understand scope for Azure RBAC
• Azure Documentation - Best practices for Azure RBAC

Defining a short log retention duration can reduce an organization’s ability to backtrace the actions of malicious actors in case of a security incident.

Logging allows operational and security teams to get detailed and real-time feedback on an information system’s events. The logging coverage enables them to quickly react to events, ranging from the most benign bugs to the most impactful security incidents, such as intrusions.

Apart from security detection, logging capabilities also directly influence future digital forensic analyses. For example, detailed logging will allow investigators to establish a timeline of the actions perpetrated by an attacker.

Ask Yourself Whether

• This component is essential for the information system infrastructure.
• This component is essential for mission-critical functions.
• Compliance policies require traceability for a longer duration.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Increase the log retention period to an amount of time sufficient enough to be able to investigate and restore service in case of an incident.

Sensitive Code Example

For Azure Firewall Policy:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Network/firewallPolicies",
      "apiVersion": "2022-07-01",
      "properties": {
        "insights": {
          "isEnabled": true,
          "retentionDays": 7
        }
      }
    }
  ]
}

resource firewallPolicy 'Microsoft.Network/firewallPolicies@2022-07-01' = {
  properties: {
    insights: {
      isEnabled: true
      retentionDays: 7  // Sensitive
    }
  }
}

For Microsoft Network Network Watchers Flow Logs:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "networkWatchers/example",
      "type": "Microsoft.Network/networkWatchers/flowLogs",
      "apiVersion": "2022-07-01",
      "properties": {
        "retentionPolicy": {
          "days": 7,
          "enabled": true
        }
      }
    }
  ]
}

resource networkWatchersFlowLogs 'Microsoft.Network/networkWatchers/flowLogs@2022-07-01' = {
  properties: {
    retentionPolicy: {
      days: 7
      enabled: true
    }
  }
}

For Microsoft SQL Servers Auditing Settings:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example/default",
      "type": "Microsoft.Sql/servers/auditingSettings",
      "apiVersion": "2021-11-01",
      "properties": {
        "retentionDays": 7,
        "state": "Enabled"
      }
    }
  ]
}

resource sqlServerAudit 'Microsoft.Sql/servers/auditingSettings@2021-11-01' = {
  properties: {
    retentionDays: 7    // Sensitive
  }
}

This rule also applies to log retention periods that are too short, on the following resources:

• Microsoft.DBforMariaDB/servers/securityAlertPolicies - for Microsoft DB for MariaDB Servers Security Alert Policies
• Microsoft.Sql/servers/databases/securityAlertPolicies - for Microsoft Sql Servers Databases Security Alert Policies
• Microsoft.Sql/servers/auditingPolicies - for Microsoft Sql Servers Auditing Policies
• Microsoft.Synapse/workspaces/auditingSettings - for Microsoft Synapse Workspaces Auditing Settings
• Microsoft.Synapse/workspaces/sqlPools/securityAlertPolicies - for Microsoft Synapse Workspaces Sql Pools Security Alert Policies

Compliant Solution

For Azure Firewall Policy:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Network/firewallPolicies",
      "apiVersion": "2022-07-01",
      "properties": {
        "insights": {
          "isEnabled": true,
          "retentionDays": 30
        }
      }
    }
  ]
}

resource firewallPolicy 'Microsoft.Network/firewallPolicies@2022-07-01' = {
  properties: {
    insights: {
      isEnabled: true
      retentionDays: 30
    }
  }
}

For Microsoft Network Network Watchers Flow Logs:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "networkWatchers/example",
      "type": "Microsoft.Network/networkWatchers/flowLogs",
      "apiVersion": "2022-07-01",
      "properties": {
        "retentionPolicy": {
          "days": 30,
          "enabled": true
        }
      }
    }
  ]
}

resource networkWatchersFlowLogs 'Microsoft.Network/networkWatchers/flowLogs@2022-07-01' = {
  properties: {
    retentionPolicy: {
      days: 30
      enabled: true
    }
  }
}

For Microsoft SQL Servers Auditing Settings:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example/default",
      "type": "Microsoft.Sql/servers/auditingSettings",
      "apiVersion": "2021-11-01",
      "properties": {
        "retentionDays": 30,
        "state": "Enabled"
      }
    }
  ]
}

resource sqlServerAudit 'Microsoft.Sql/servers/auditingSettings@2021-11-01' = {
  properties: {
    retentionDays: 30
  }
}

Above code also applies to other types defined in previous paragraph.

Disabling certificate-based authentication can reduce an organization’s ability to react against attacks on its critical functions and data.

Azure offers various authentication options to access resources: Anonymous connections, Basic authentication, password-based authentication, and certificate-based authentication.

Choosing certificate-based authentication helps bring client/host trust by allowing the host to verify the client and vice versa. It cannot be forged or forwarded by a man-in-the-middle eavesdropper, and the certificate’s private key is never sent over the network so it’s harder to steal than a password.

In case of a security incident, certificates help bring investigators traceability and allow security operations teams to react faster. For example, all compromised certificates could be revoked individually, or an issuing certificate could be revoked which causes all the certificates it issued to become untrusted.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• Compliance policies require access to this resource to be authenticated with certificates.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Enable certificate-based authentication.

Sensitive Code Example

Where the use of client certificates is controlled by a boolean value, such as:

• Microsoft.Web/sites with clientCertEnabled
• Microsoft.SignalRService/signalR with tls → clientCertEnabled
• Microsoft.SignalRService/webPubSub with tls → clientCertEnabled
• Microsoft.ApiManagement/service/gateways/hostnameConfigurations with negotiateClientCertificate

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.SignalRService/webPubSub",
      "apiVersion": "2020-07-01-preview",
      "name": "example",
      "properties": {
        "tls": {
          "clientCertEnabled": false
        }
      }
    }
  ]
}

resource example 'Microsoft.SignalRService/webPubSub@2020-07-01-preview' = {
  name: 'example'
  properties: {
    tls: {
      clientCertEnabled: false // Sensitive
    }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2015-08-01",
      "name": "example",
      "properties": {
        "clientCertEnabled": false
      }
    }
  ]
}

resource example 'Microsoft.Web/sites@2015-08-01' = {
  name: 'example'
  properties: {
    clientCertEnabled: false // Sensitive
  }
}

Where the use of client certificates can be made optional, such as:

• Microsoft.Web/sites with clientCertMode
• Microsoft.App/containerApps with configuration → ingress → clientCertificateMode

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2015-08-01",
      "name": "example",
      "properties": {
        "clientCertEnabled": true,
        "clientCertMode": "Optional"
      }
    }
  ]
}

resource example 'Microsoft.Web/sites@2015-08-01' = {
  name: 'example'
  properties: {
    clientCertEnabled: true
    clientCertMode: 'Optional' // Sensitive
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.App/containerApps",
      "apiVersion": "2022-10-01",
      "name": "example",
      "properties": {
        "configuration": {
          "ingress": {
            "clientCertificateMode": "accept"
          }
        }
      }
    }
  ]
}

resource example 'Microsoft.App/containerApps@2022-10-01' = {
  name: 'example'
  properties: {
    configuration: {
      ingress: {
        clientCertificateMode: 'accept' // Sensitive
      }
    }
  }
}

Where client certificates can be used to authenticate outbound requests, such as:

• Microsoft.DataFactory/factories/linkedservices with typeProperties → authenticationType where the request type is Web or HttpServer
• Microsoft.DataFactory/factories/pipelines with activites → typeProperties → authentication → type where the activity type is WebActivity or WebHook
• Microsoft.Scheduler/jobCollections/jobs with action → request → authentication → type
• Microsoft.Scheduler/jobCollections/jobs with action → errorAction → request → authentication → type

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DataFactory/factories/linkedservices",
      "apiVersion": "2018-06-01",
      "name": "factories/example",
      "properties": {
        "type": "Web",
        "typeProperties": {
          "authenticationType": "Basic"
        }
      }
    }
  ]
}

resource example 'Microsoft.DataFactory/factories/linkedservices@2018-06-01' = {
  name: 'example'
  properties: {
    type: 'Web'
    typeProperties: {
      authenticationType: 'Basic' // Sensitive
    }
  }
}

Where a list of permitted client certificates must be provided, such as:

• Microsoft.DocumentDB/cassandraClusters with clientCertificates
• Microsoft.Network/applicationGateways with trustedClientCertificates
• Microsoft.ServiceFabric/clusters with clientCertificateCommonNames or clientCertificateThumbprints

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DocumentDB/cassandraClusters",
      "apiVersion": "2021-10-15",
      "name": "example",
      "properties": {
        "clientCertificates": []
      }
    }
  ]
}

resource example 'Microsoft.DocumentDB/cassandraClusters@2021-10-15' = {
  name: 'example'
  properties: {
    clientCertificates: [] // Sensitive
  }
}

Where a resouce can use both certificate-based and password-based authentication, such as:

• Microsoft.ContainerRegistry/registries/tokens with credentials → certficates and credentials → passwords

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.ContainerRegistry/registries/tokens",
      "apiVersion": "2022-12-01",
      "name": "registries/example",
      "properties": {
        "credentials": {
          "passwords": [
            {
              "name": "password1"
            }
          ]
        }
      }
    }
  ]
}

resource example 'Microsoft.ContainerRegistry/registries/tokens@2022-12-01' = {
  name: 'example'
  properties: {
    credentials: {
      passwords: [ // Sensitive
        {
          name: 'password1'
        }
      ]
    }
  }
}

Compliant Solution

Where the use of client certificates is controlled by a boolean value:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.SignalRService/webPubSub",
      "apiVersion": "2020-07-01-preview",
      "name": "example",
      "properties": {
        "tls": {
          "clientCertEnabled": true
        }
      }
    }
  ]
}

resource example 'Microsoft.SignalRService/webPubSub@2020-07-01-preview' = {
  name: 'example'
  properties: {
    tls: {
      clientCertEnabled: true
    }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2015-08-01",
      "name": "example",
      "properties": {
        "clientCertEnabled": true,
        "clientCertMode": "Required"
      }
    }
  ]
}

resource example 'Microsoft.Web/sites@2015-08-01' = {
  name: 'example'
  properties: {
    clientCertEnabled: true
    clientCertMode: 'Required'
  }
}

Where the use of client certificates can be made optional:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2015-08-01",
      "name": "example",
      "properties": {
        "clientCertEnabled": true,
        "clientCertMode": "Required"
      }
    }
  ]
}

resource example 'Microsoft.Web/sites@2015-08-01' = {
  name: 'example'
  properties: {
    clientCertEnabled: true
    clientCertMode: 'Required'
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.App/containerApps",
      "apiVersion": "2022-10-01",
      "name": "example",
      "properties": {
        "configuration": {
          "ingress": {
            "clientCertificateMode": "require"
          }
        }
      }
    }
  ]
}

resource example 'Microsoft.App/containerApps@2022-10-01' = {
  name: 'example'
  properties: {
    configuration: {
      ingress: {
        clientCertificateMode: 'require'
      }
    }
  }
}

Where client certificates can be used to authenticate outbound requests:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DataFactory/factories/linkedservices",
      "apiVersion": "2018-06-01",
      "name": "example",
      "properties": {
        "type": "Web",
        "typeProperties": {
          "authenticationType": "ClientCertificate"
        }
      }
    }
  ]
}

resource example 'Microsoft.DataFactory/factories/linkedservices@2018-06-01' = {
  name: 'example'
  properties: {
    type: 'Web'
    typeProperties: {
      authenticationType: 'ClientCertificate'
    }
  }
}

Where a list of permitted client certificates must be provided:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.DocumentDB/cassandraClusters",
      "apiVersion": "2021-10-15",
      "name": "example",
      "properties": {
        "clientCertificates": [
          {
            "pem": "[base64-encoded certificate]"
          }
        ]
      }
    }
  ]
}

resource example 'Microsoft.DocumentDB/cassandraClusters@2021-10-15' = {
  name: 'example'
  properties: {
    clientCertificates: [
      {
        pem: '[base64-encoded certificate]'
      }
    ]
  }
}

Where a resouce can use both certificate-based and password-based authentication:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.ContainerRegistry/registries/tokens",
      "apiVersion": "2022-12-01",
      "name": "example",
      "properties": {
        "credentials": {
          "certificates": [
            {
              "name": "certificate1",
              "encodedPemCertificate": "[base64-encoded certificate]"
            }
          ]
        }
      }
    }
  ]
}

resource example 'Microsoft.ContainerRegistry/registries/tokens@2022-12-01' = {
  name: 'example'
  properties: {
    credentials: {
      certificates: [
        {
          name: 'certificate1'
          encodedPemCertificate: '[base64-encoded certificate]'
        }
      ]
    }
  }
}

See

• Azure Resource Manager templates
• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Disabling Role-Based Access Control (RBAC) on Azure resources can reduce an organization’s ability to protect itself against access controls being compromised.

To be considered safe, access controls must follow the principle of least privilege and correctly segregate duties amongst users. RBAC helps enforce these practices by adapting the organization’s access control needs into explicit role-based policies: It helps keeping access controls maintainable and sustainable.

Furthermore, RBAC allows operations teams to work faster during a security incident. It helps to mitigate account theft or intrusions by quickly shutting down accesses.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• Compliance policies require access to this resource to be enforced through the use of Role-Based Access Control.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Enable Azure RBAC when the Azure resource supports it.
• For Kubernetes clusters, enable Azure RBAC if Azure AD integration is supported. Otherwise, use the built-in Kubernetes RBAC.

Sensitive Code Example

For AKS Azure Kubernetes Service:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2023-03-01",
      "properties": {
        "aadProfile": {
          "enableAzureRBAC": false
        },
        "enableRBAC": false
      }
    }
  ]
}

resource aks 'Microsoft.ContainerService/managedClusters@2023-03-01' = {
  properties: {
    aadProfile: {
      enableAzureRBAC: false    // Sensitive
    }
    enableRBAC: false           // Sensitive
  }
}

For Key Vault:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.KeyVault/vaults",
      "apiVersion": "2022-07-01",
      "properties": {
        "enableRbacAuthorization": false
      }
    }
  ]
}

resource keyVault 'Microsoft.KeyVault/vaults@2022-07-01' = {
  properties: {
    enableRbacAuthorization: false    // Sensitive
  }
}

Compliant Solution

For AKS Azure Kubernetes Service:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2023-03-01",
      "properties": {
        "aadProfile": {
          "enableAzureRBAC": true
        },
        "enableRBAC": true
      }
    }
  ]
}

resource aks 'Microsoft.ContainerService/managedClusters@2023-03-01' = {
  properties: {
    aadProfile: {
      enableAzureRBAC: true     // Compliant
    }
    enableRBAC: true            // Compliant
  }
}

For Key Vault:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.KeyVault/vaults",
      "apiVersion": "2022-07-01",
      "properties": {
        "enableRbacAuthorization": true
      }
    }
  ]
}

resource keyVault 'Microsoft.KeyVault/vaults@2022-07-01' = {
  properties: {
    enableRbacAuthorization: true    // Compliant
  }
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Clear-text protocols such as ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

• sensitive data exposure
• traffic redirected to a malicious endpoint
• malware-infected software update or installer
• execution of client-side code
• corruption of critical information

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

• bypassing isolation mechanisms
• compromising a component of the network
• getting the credentials of an internal IAM account (either from a service account or an actual person)

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

• CVE-2019-6169
• CVE-2019-12327
• CVE-2019-11065

Ask Yourself Whether

• Application data needs to be protected against falsifications or leaks when transiting over the network.
• Application data transits over an untrusted network.
• Compliance rules require the service to encrypt data in transit.
• Your application renders web pages with a relaxed mixed content policy.
• OS-level protections against clear-text traffic are deactivated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Make application data transit over a secure, authenticated and encrypted protocol like TLS or SSH. Here are a few alternatives to the most common clear-text protocols:
  • Use ssh as an alternative to telnet.
  • Use sftp, scp, or ftps instead of ftp.
  • Use https instead of http.
  • Use SMTP over SSL/TLS or SMTP with STARTTLS instead of clear-text SMTP.
• Enable encryption of cloud components communications whenever it is possible.
• Configure your application to block mixed content when rendering web pages.
• If available, enforce OS-level deactivation of all clear-text traffic.

It is recommended to secure all transport channels, even on local networks, as it can take a single non-secure connection to compromise an entire application or system.

Sensitive Code Example

For AWS Kinesis Data Streams server-side encryption:

resource "aws_kinesis_stream" "sensitive_stream" {
    encryption_type = "NONE" # Sensitive
}

For Amazon ElastiCache:

resource "aws_elasticache_replication_group" "example" {
    replication_group_id = "example"
    replication_group_description = "example"
    transit_encryption_enabled = false  # Sensitive
}

For Amazon ECS:

resource "aws_ecs_task_definition" "ecs_task" {
  family = "service"
  container_definitions = file("task-definition.json")

  volume {
    name = "storage"
    efs_volume_configuration {
      file_system_id = aws_efs_file_system.fs.id
      transit_encryption = "DISABLED"  # Sensitive
    }
  }
}

For Amazon OpenSearch domains:

resource "aws_elasticsearch_domain" "example" {
  domain_name = "example"
  domain_endpoint_options {
    enforce_https = false # Sensitive
  }
  node_to_node_encryption {
    enabled = false # Sensitive
  }
}

For Amazon MSK communications between clients and brokers:

resource "aws_msk_cluster" "sensitive_data_cluster" {
    encryption_info {
        encryption_in_transit {
            client_broker = "TLS_PLAINTEXT" # Sensitive
            in_cluster = false # Sensitive
        }
    }
}

For AWS Load Balancer Listeners:

resource "aws_lb_listener" "front_load_balancer" {
  protocol = "HTTP" # Sensitive

  default_action {
    type = "redirect"

    redirect {
      protocol = "HTTP"
    }
  }
}

HTTP protocol is used for GCP Region Backend Services:

resource "google_compute_region_backend_service" "example" {
  name                            = "example-service"
  region                          = "us-central1"
  health_checks                   = [google_compute_region_health_check.region.id]
  connection_draining_timeout_sec = 10
  session_affinity                = "CLIENT_IP"
  load_balancing_scheme           = "EXTERNAL"
  protocol                        = "HTTP" # Sensitive
}

Compliant Solution

For AWS Kinesis Data Streams server-side encryption:

resource "aws_kinesis_stream" "compliant_stream" {
    encryption_type = "KMS"
}

For Amazon ElastiCache:

resource "aws_elasticache_replication_group" "example" {
    replication_group_id = "example"
    replication_group_description = "example"
    transit_encryption_enabled = true
}

For Amazon ECS:

resource "aws_ecs_task_definition" "ecs_task" {
  family = "service"
  container_definitions = file("task-definition.json")

  volume {
    name = "storage"
    efs_volume_configuration {
      file_system_id = aws_efs_file_system.fs.id
      transit_encryption = "ENABLED"
    }
  }
}

For Amazon OpenSearch domains:

resource "aws_elasticsearch_domain" "example" {
  domain_name = "example"
  domain_endpoint_options {
    enforce_https = true
  }
  node_to_node_encryption {
    enabled = true
  }
}

For Amazon MSK communications between clients and brokers, data in transit is encrypted by default, allowing you to omit writing the encryption_in_transit configuration. However, if you need to configure it explicitly, this configuration is compliant:

resource "aws_msk_cluster" "sensitive_data_cluster" {
    encryption_info {
        encryption_in_transit {
            client_broker = "TLS"
            in_cluster = true
        }
    }
}

For AWS Load Balancer Listeners:

resource "aws_lb_listener" "front_load_balancer" {
  protocol = "HTTP"

  default_action {
    type = "redirect"

    redirect {
      protocol = "HTTPS"
    }
  }
}

HTTPS protocol is used for GCP Region Backend Services:

resource "google_compute_region_backend_service" "example" {
  name                            = "example-service"
  region                          = "us-central1"
  health_checks                   = [google_compute_region_health_check.region.id]
  connection_draining_timeout_sec = 10
  session_affinity                = "CLIENT_IP"
  load_balancing_scheme           = "EXTERNAL"
  protocol                        = "HTTPS"
}

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Insecure protocol scheme followed by loopback addresses like 127.0.0.1 or localhost.

See

• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• CWE - CWE-319 - Cleartext Transmission of Sensitive Information
• Google, Moving towards more secure web
• Mozilla, Deprecating non secure http
• AWS Documentation - Listeners for your Application Load Balancers
• AWS Documentation - Stream Encryption

A policy that grants all permissions may indicate an improper access control, which violates the principle of least privilege. Suppose an identity is granted full permissions to a resource even though it only requires read permission to work as expected. In this case, an unintentional overwriting of resources may occur and therefore result in loss of information.

Ask Yourself Whether

Identities obtaining all the permissions:

• only require a subset of these permissions to perform the intended function.
• have monitored activity showing that only a subset of these permissions is actually used.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to apply the least privilege principle, i.e. by only granting the necessary permissions to identities. A good practice is to start with the very minimum set of permissions and to refine the policy over time. In order to fix overly permissive policies already deployed in production, a strategy could be to review the monitored activity in order to reduce the set of permissions to those most used.

Sensitive Code Example

A customer-managed policy for AWS that grants all permissions by using the wildcard (*) in the Action property:

resource "aws_iam_policy" "example" {
  name = "noncompliantpolicy"

  policy = jsonencode({
    Version   = "2012-10-17"
    Statement = [
      {
        Action   = [
          "*" # Sensitive
        ]
        Effect   = "Allow"
        Resource = [
          aws_s3_bucket.mybucket.arn
        ]
      }
    ]
  })
}

A customer-managed policy for GCP that grants all permissions by using the actions admin role role property:

resource "google_project_iam_binding" "example" {
  project = "example"
  role    = "roles/owner" # Sensitive

  members = [
    "user:jane@example.com",
  ]
}

Compliant Solution

A customer-managed policy for AWS that grants only the required permissions:

resource "aws_iam_policy" "example" {
  name = "compliantpolicy"

  policy = jsonencode({
    Version   = "2012-10-17"
    Statement = [
      {
        Action   = [
          "s3:GetObject"
        ]
        Effect   = "Allow"
        Resource = [
          aws_s3_bucket.mybucket.arn
        ]
      }
    ]
  })
}

A customer-managed policy for GCP that grants restricted permissions by using the actions admin role role property:

resource "google_project_iam_binding" "example" {
  project = "example"
  role    = "roles/actions.Viewer"

  members = [
    "user:jane@example.com",
  ]
}

See

• AWS Documentation - Grant least privilege
• Google Cloud Documentation - Understanding roles
• CWE - CWE-732 - Incorrect Permission Assignment for Critical Resource
• CWE - CWE-284 - Improper Access Control

Using unencrypted RDS DB resources exposes data to unauthorized access.
This includes database data, logs, automatic backups, read replicas, snapshots, and cluster metadata.

This situation can occur in a variety of scenarios, such as:

• A malicious insider working at the cloud provider gains physical access to the storage device.
• Unknown attackers penetrate the cloud provider’s logical infrastructure and systems.

After a successful intrusion, the underlying applications are exposed to:

• theft of intellectual property and/or personal data
• extortion
• denial of services and security bypasses via data corruption or deletion

AWS-managed encryption at rest reduces this risk with a simple switch.

Ask Yourself Whether

• The database contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It is recommended to enable encryption at rest on any RDS DB resource, regardless of the engine.
In any case, no further maintenance is required as encryption at rest is fully managed by AWS.

Sensitive Code Example

For aws_db_instance and aws_rds_cluster:

resource "aws_db_instance" "example" {
  storage_encrypted = false # Sensitive, disabled by default
}

resource "aws_rds_cluster" "example" {
  storage_encrypted = false # Sensitive, disabled by default
}

Compliant Solution

For aws_db_instance and aws_rds_cluster:

resource "aws_db_instance" "example" {
  storage_encrypted = true
}

resource "aws_rds_cluster" "example" {
  storage_encrypted = true
}

See

• AWS Documentation - Encrypting Amazon RDS resources
• CWE - CWE-311 - Missing Encryption of Sensitive Data

A policy that allows identities to access all resources in an AWS account may violate the principle of least privilege. Suppose an identity has permission to access all resources even though it only requires access to some non-sensitive ones. In this case, unauthorized access and disclosure of sensitive information will occur.

Ask Yourself Whether

The AWS account has more than one resource with different levels of sensitivity.

A risk exists if you answered yes to this question.

Recommended Secure Coding Practices

It’s recommended to apply the least privilege principle, i.e., by only granting access to necessary resources. A good practice to achieve this is to organize or tag resources depending on the sensitivity level of data they store or process. Therefore, managing a secure access control is less prone to errors.

Sensitive Code Example

Update permission is granted for all policies using the wildcard (*) in the Resource property:

resource "aws_iam_policy" "noncompliantpolicy" {
  name        = "noncompliantpolicy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "iam:CreatePolicyVersion"
        ]
        Effect   = "Allow"
        Resource = [
          "*" # Sensitive
        ]
      }
    ]
  })
}

Compliant Solution

Restrict update permission to the appropriate subset of policies:

resource "aws_iam_policy" "compliantpolicy" {
  name        = "compliantpolicy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "iam:CreatePolicyVersion"
        ]
        Effect   = "Allow"
        Resource = [
          "arn:aws:iam::${data.aws_caller_identity.current.account_id}:policy/team1/*"
        ]
      }
    ]
  })
}

Exceptions

• Should not be raised on key policies (when AWS KMS actions are used.)
• Should not be raised on policies not using any resources (if and only if all actions in the policy never require resources.)

See

• AWS Documentation - Grant least privilege
• CWE - CWE-732 - Incorrect Permission Assignment for Critical Resource
• CWE - CWE-284 - Improper Access Control

Using unencrypted cloud storages can lead to data exposure. In the case that adversaries gain physical access to the storage medium they are able to access unencrypted information.

Ask Yourself Whether

• The service contains sensitive information that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt cloud storages that contain sensitive information.

Sensitive Code Example

For azurerm_data_lake_store:

resource "azurerm_data_lake_store" "store" {
  name             = "store"
  encryption_state = "Disabled"  # Sensitive
}

Compliant Solution

For azurerm_data_lake_store:

resource "azurerm_data_lake_store" "store" {
  name             = "store"
  encryption_state = "Enabled"
  encryption_type  = "ServiceManaged"
}

See

• Data encryption in Amazon EFS
• CWE - CWE-311 - Missing Encryption of Sensitive Data
• Encryption in Azure Backup
• Security in Azure Database for MySQL
• Security in Azure Database for PostgreSQL
• Infrastructure double encryption of data

Predefined permissions, also known as canned ACLs, are an easy way to grant large privileges to predefined groups or users.

The following canned ACLs are security-sensitive:

• PublicRead, PublicReadWrite grant respectively "read" and "read and write" privileges to everyone in the world (AllUsers group).
• AuthenticatedRead grants "read" privilege to all authenticated users (AuthenticatedUsers group).

Ask Yourself Whether

• The S3 bucket stores sensitive data.
• The S3 bucket is not used to store static resources of websites (images, css …​).

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to implement the least privilege policy, ie to grant necessary permissions only to users for their required tasks. In the context of canned ACL, set it to private (the default one) and if needed more granularity then use an appropriate S3 policy.

Sensitive Code Example

All users (ie: anyone in the world authenticated or not) have read and write permissions with the public-read-write access control:

resource "aws_s3_bucket" "mynoncompliantbucket" { # Sensitive
  bucket = "mynoncompliantbucketname"
  acl    = "public-read-write"
}

Compliant Solution

With the private access control (default), only the bucket owner has the read/write permissions on the buckets and its ACL.

resource "aws_s3_bucket" "mycompliantbucket" { # Compliant
  bucket = "mycompliantbucketname"
  acl    = "private"
}

See

• AWS Documentation - Access control list (ACL) overview (canned ACLs)
• AWS Documentation - Controlling access to a bucket with user policies
• CWE - CWE-732 - Incorrect Permission Assignment for Critical Resource
• CWE - CWE-284 - Improper Access Control

Amazon Elasticsearch Service (ES) is a managed service to host Elasticsearch instances.

To harden domain (cluster) data in case of unauthorized access, ES provides data-at-rest encryption if the Elasticsearch version is 5.1 or above. Enabling encryption at rest will help protect:

• indices
• logs
• swap files
• data in the application directory
• automated snapshots

Thus, if adversaries gain physical access to the storage medium, they cannot access the data.

Ask Yourself Whether

• The database contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It is recommended to encrypt Elasticsearch domains that contain sensitive information.

Encryption and decryption are handled transparently by ES, so no further modifications to the application are necessary.

Sensitive Code Example

For aws_elasticsearch_domain:

resource "aws_elasticsearch_domain" "elasticsearch" {
  encrypt_at_rest {
    enabled = false  # Sensitive, disabled by default
  }
}

Compliant Solution

For aws_elasticsearch_domain:

resource "aws_elasticsearch_domain" "elasticsearch" {
  encrypt_at_rest {
    enabled = true
  }
}

See

• AWS Documentation - Encryption of data at rest for Amazon Elasticsearch Service
• CWE - CWE-311 - Missing Encryption of Sensitive Data

Allowing anonymous access can reduce an organization’s ability to protect itself against attacks on its Azure resources.

Security incidents may include disrupting critical functions, data theft, and additional Azure subscription costs due to resource overload.

Using authentication coupled with fine-grained authorizations helps bring defense-in-depth and bring traceability to investigators of security incidents.

Depending on the affected Azure resource, multiple authentication choices are possible: Active Directory Authentication, OpenID implementations (Google, Microsoft, etc.) or native Azure mechanisms.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• This Azure resource stores or processes sensitive data.
• Compliance policies require access to this resource to be authenticated.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Enable authentication in this Azure resource, and disable anonymous access.

If only Basic Authentication is available, enable it.

Sensitive Code Example

For App Services and equivalent:

resource "azurerm_function_app" "example" {
  name = "example"

  auth_settings {
    enabled = false # Sensitive
  }

  auth_settings {
    enabled = true
    unauthenticated_client_action = "AllowAnonymous" # Sensitive
  }
}

For API Management:

resource "azurerm_api_management_api" "example" { # Sensitive, the openid_authentication block is missing
  name = "example-api"
}

resource "azurerm_api_management" "example" {
  sign_in {
    enabled = false # Sensitive
  }
}

For Data Factory Linked Services:

resource "azurerm_data_factory_linked_service_sftp" "example" {
  authentication_type = "Anonymous"
}

For Storage Accounts:

resource "azurerm_storage_account" "example" {
  allow_blob_public_access = true # Sensitive
}

resource "azurerm_storage_container" "example" {
  container_access_type = "blob" # Sensitive
}

For Redis Caches:

resource "azurerm_redis_cache" "example" {
  name = "example-cache"

  redis_configuration {
    enable_authentication = false # Sensitive
  }
}

Compliant Solution

For App Services and equivalent:

resource "azurerm_function_app" "example" {
  name = "example"

  auth_settings {
    enabled = true
    unauthenticated_client_action = "RedirectToLoginPage"
  }
}

For API Management:

resource "azurerm_api_management_api" "example" {
  name = "example-api"

  openid_authentication {
    openid_provider_name = azurerm_api_management_openid_connect_provider.example.name
  }
}

resource "azurerm_api_management" "example" {
  sign_in {
    enabled = true
  }
}

For Data Factory Linked Services:

resource "azurerm_data_factory_linked_service_sftp" "example" {
  authentication_type = "Basic"
  username            = local.creds.username
  password            = local.creds.password
}

resource "azurerm_data_factory_linked_service_odata" "example" {
  basic_authentication {
    username = local.creds.username
    password = local.creds.password
  }
}

For Storage Accounts:

resource "azurerm_storage_account" "example" {
  allow_blob_public_access = true
}

resource "azurerm_storage_container" "example" {
  container_access_type = "private"
}

For Redis Caches:

resource "azurerm_redis_cache" "example" {
  name = "example-cache"

  redis_configuration {
    enable_authentication = true
  }
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Azure Resource Manager offers built-in roles that can be assigned to users, groups, or service principals. Some of these roles should be carefully assigned as they grant sensitive permissions like the ability to reset passwords for all users.

An Azure account that fails to limit the use of such roles has a higher risk of being breached by a compromised owner.

This rule raises an issue when one of the following roles is assigned:

• Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c)
• Owner (8e3af657-a8ff-443c-a75c-2fe8c4bcb635)
• User Access Administrator (18d7d88d-d35e-4fb5-a5c3-7773c20a72d9)

Ask Yourself Whether

• The user, group, or service principal doesn’t use the entirety of this extensive set of permissions to operate on a day-to-day basis.
• It is possible to follow the Separation of Duties principle and split permissions between multiple users, but it’s not enforced.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

• Limit the assignment of Owner roles to less than 3 people or service principals.
• Apply the least privilege principle by choosing a role with a limited set of permissions.
• If no built-in role meets your needs, create a custom role with as few permissions as possible.

Sensitive Code Example

resource "azurerm_role_assignment" "example" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Owner" # Sensitive
  principal_id         = data.azuread_user.example.id
}

Compliant Solution

resource "azurerm_role_assignment" "example" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Azure Maps Data Reader"
  principal_id         = data.azuread_user.example.id
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• Azure Documentation - Azure built-in roles
• Azure Documentation - Best practices for Azure RBAC

Disabling certificate-based authentication can reduce an organization’s ability to react against attacks on its critical functions and data.

Azure offers various authentication options to access resources: Anonymous connections, Basic authentication, password-based authentication, and certificate-based authentication.

Choosing certificate-based authentication helps bring client/host trust by allowing the host to verify the client and vice versa. It cannot be forged or forwarded by a man-in-the-middle eavesdropper, and the certificate’s private key is never sent over the network so it’s harder to steal than a password.

In case of a security incident, certificates help bring investigators traceability and allow security operations teams to react faster. For example, all compromised certificates could be revoked individually, or an issuing certificate could be revoked which causes all the certificates it issued to become untrusted.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• Compliance policies require access to this resource to be authenticated with certificates.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Enable certificate-based authentication.

Sensitive Code Example

For App Service:

resource "azurerm_app_service" "example" {
  client_cert_enabled = false # Sensitive
}

For Logic App Standards and Function Apps:

resource "azurerm_function_app" "example" {
  client_cert_mode = "Optional" # Sensitive
}

For Data Factory Linked Services:

resource "azurerm_data_factory_linked_service_web" "example" {
  authentication_type = "Basic" # Sensitive
}

For API Management:

resource "azurerm_api_management" "example" {
  sku_name = "Consumption_1"
  client_certificate_mode = "Optional" # Sensitive
}

For Linux and Windows Web Apps:

resource "azurerm_linux_web_app" "example" {
  client_cert_enabled = false # Sensitive
}
resource "azurerm_linux_web_app" "exemple2" {
  client_cert_enabled = true
  client_cert_mode = "Optional" # Sensitive
}

Compliant Solution

For App Service:

resource "azurerm_app_service" "example" {
  client_cert_enabled = true
}

For Logic App Standards and Function Apps:

resource "azurerm_function_app" "example" {
  client_cert_mode = "Required"
}

For Data Factory Linked Services:

resource "azurerm_data_factory_linked_service_web" "example" {
  authentication_type = "ClientCertificate"
}

For API Management:

resource "azurerm_api_management" "example" {
  sku_name = "Consumption_1"
  client_certificate_mode = "Required"
}

For Linux and Windows Web Apps:

resource "azurerm_linux_web_app" "exemple" {
  client_cert_enabled = true
  client_cert_mode = "Required"
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Disabling Role-Based Access Control (RBAC) on Azure resources can reduce an organization’s ability to protect itself against access controls being compromised.

To be considered safe, access controls must follow the principle of least privilege and correctly segregate duties amongst users. RBAC helps enforce these practices by adapting the organization’s access control needs into explicit role-based policies: It helps keeping access controls maintainable and sustainable.

Furthermore, RBAC allows operations teams to work faster during a security incident. It helps to mitigate account theft or intrusions by quickly shutting down accesses.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• Compliance policies require access to this resource to be enforced through the use of Role-Based Access Control.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Enable Azure RBAC when the Azure resource supports it.
• For Kubernetes clusters, enable Azure RBAC if Azure AD integration is supported. Otherwise, use the built-in Kubernetes RBAC.

Sensitive Code Example

For Azure Kubernetes Services:

resource "azurerm_kubernetes_cluster" "example" {
  role_based_access_control {
    enabled = false # Sensitive
  }
}

resource "azurerm_kubernetes_cluster" "example2" {
  role_based_access_control {
    enabled = true

    azure_active_directory {
      managed = true
      azure_rbac_enabled = false # Sensitive
    }
  }
}

For Key Vaults:

resource "azurerm_key_vault" "example" {
  enable_rbac_authorization = false # Sensitive
}

Compliant Solution

For Azure Kubernetes Services:

resource "azurerm_kubernetes_cluster" "example" {
  role_based_access_control {
    enabled = true
  }
}

resource "azurerm_kubernetes_cluster" "example" {
  role_based_access_control {
    enabled = true

    azure_active_directory {
      managed = true
      azure_rbac_enabled = true
    }
  }
}

For Key Vaults:

resource "azurerm_key_vault" "example" {
  enable_rbac_authorization   = true
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Defining a custom role at the Subscription or Management group scope that allows all actions will give it the same capabilities as the built-in Owner role.

Why is this an issue?

In Azure, the Owner role of a Subscription or a Management group provides entities it is assigned to with the maximum level of privileges. The Owner role allows managing all resources and assigning any role to other entities.

Because it is a powerful entitlement, it should be granted to as few users as possible.

When a custom role has the same level of permissions as the Owner one, there are greater chances that high privileges are granted to too many users.

What is the potential impact?

Custom roles that provide the same level of permissions as Owner might indicate a configuration issue. Any entity assigned with it can perform any action on the Subscription or Management group, including changing roles and permissions.

If the affected role is unexpectedly assigned to users, they can compromise the affected scope. They can do so in the long term by assigning dangerous roles to other users or entities.

Depending on the scope to which the role is assignable, the exact impact of a successful exploitation may vary. It generally ranges from data compromise to the takeover of the cloud infrastructure.

Infrastructure takeover

By obtaining the right role, an attacker can gain control over part or all of the Azure infrastructure. They can modify DNS settings, redirect traffic, or launch malicious instances that can be used for various nefarious activities, including launching DDoS attacks, hosting phishing websites, or distributing malware. Malicious instances may also be used for resource-intensive tasks such as cryptocurrency mining.

This can result in legal liability, but also increased costs, degraded performance, and potential service disruptions.

Furthermore, corporate Azure infrastructures are often connected to other services and to the internal networks of the organization. Because of this, cloud infrastructure is often used by attackers as a gateway to other assets. Attackers can leverage this gateway to gain access to more services, to compromise more business-critical data, and to cause more damage to the overall infrastructure.

Compromise of sensitive data

If the affected service is used to store or process personally identifiable information or other sensitive data, attackers with the correct role could be able to access it. Depending on the type of data that is compromised, it could lead to privacy violations, identity theft, financial loss, or other negative outcomes.

In most cases, a company suffering a sensitive data compromise will face a reputational loss when the security issue is publicly disclosed.

Financial loss

Financial losses can occur when a malicious user is able to use a paid third-party-provided service. Each users assigned with a bad role will be able to use it without limit to use the third party service to their own need, including in a way that was not expected.

This additional use will lead to added costs with the Azure service provider.

Moreover, when rate or volume limiting is set up on the provider side, this additional use can prevent the regular operation of the affected environment. This might result in a partial denial of service for all legitimate users.

How to fix it

To reduce the risk of intrusion of a compromised owner, it is recommended to limit the number of subscription owners.

Code examples

Noncompliant code example

resource "azurerm_role_definition" "example" { # Sensitive
  name        = "example"
  scope       = data.azurerm_subscription.primary.id

  permissions {
    actions     = ["*"]
    not_actions = []
  }

  assignable_scopes = [
    data.azurerm_subscription.primary.id
  ]
}

Compliant solution

resource "azurerm_role_definition" "example" {
  name        = "example"
  scope       = data.azurerm_subscription.primary.id

  permissions {
    actions     = ["Microsoft.Compute/*"]
    not_actions = []
  }

  assignable_scopes = [
    data.azurerm_subscription.primary.id
  ]
}

Going the extra mile

Here is a list of recommendations that can be followed regarding good usage of roles:

• Apply the least privilege principle by creating a custom role with as few permissions as possible.
• As custom roles can be updated, gradually add atomic permissions when required.
• Limit the assignable scopes of the custom role to a set of Resources or Resource Groups.
• When necessary, use the built-in Owner role instead of a custom role granting subscription owner capabilities.
• Limit the assignments of Owner roles to less than three people or service principals.

Resources

Documentation

• Azure Documentation - Azure custom roles
• Azure Documentation - Best practices for Azure RBAC

Standards

• CWE - CWE-266 - Incorrect Privilege Assignment

Azure RBAC roles can be assigned to users, groups, or service principals. A role assignment grants permissions on a predefined set of resources called "scope".

The widest scopes a role can be assigned to are:

• Subscription: a role assigned with this scope grants access to all resources of this Subscription.
• Management Group: a scope assigned with this scope grants access to all resources of all the Subscriptions in this Management Group.

In case of security incidents involving a compromised identity (user, group, or service principal), limiting its role assignment to the narrowest scope possible helps separate duties and limits what resources are at risk.

Ask Yourself Whether

• The user, group, or service principal doesn’t use the entirety of the resources in the scope to operate on a day-to-day basis.
• It is possible to follow the Separation of Duties principle and split the scope into multiple role assignments with a narrower scope.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

• Limit the scope of the role assignment to a Resource or Resource Group.
• Apply the least privilege principle by assigning roles granting as few permissions as possible.

Sensitive Code Example

resource "azurerm_role_assignment" "example" {
  scope                = data.azurerm_subscription.primary.id # Sensitive
  role_definition_name = "Reader"
  principal_id         = data.azuread_user.user.object_id
}

Compliant Solution

resource "azurerm_role_assignment" "example" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Reader"
  principal_id         = data.azuread_user.user.object_id
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• Azure Documentation - Understand scope for Azure RBAC
• Azure Documentation - Best practices for Azure RBAC

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

To provide communication security over a network, SSL and TLS are generally used. However, it is important to note that the following protocols are all considered weak by the cryptographic community, and are officially deprecated:

• SSL versions 1.0, 2.0 and 3.0
• TLS versions 1.0 and 1.1

When these unsecured protocols are used, it is best practice to expect a breach: that a user or organization with malicious intent will perform mathematical attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in AWS API Gateway

Code examples

These code samples illustrate how to fix this issue in both APIGateway and ApiGatewayV2.

Noncompliant code example

resource "aws_api_gateway_domain_name" "example" {
  domain_name = "api.example.com"
  security_policy = "TLS_1_0" # Noncompliant
}

The ApiGatewayV2 uses a weak TLS version by default:

resource "aws_apigatewayv2_domain_name" "example" {
  domain_name = "api.example.com"
  domain_name_configuration {} # Noncompliant
}

Compliant solution

resource "aws_api_gateway_domain_name" "example" {
  domain_name = "api.example.com"
  security_policy = "TLS_1_2"
}

resource "aws_apigatewayv2_domain_name" "example" {
  domain_name = "api.example.com"
  domain_name_configuration {
    security_policy = "TLS_1_2"
  }
}

How does this work?

As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The best choices at the moment are the following.

Use TLS v1.2 or TLS v1.3

Even though TLS V1.3 is available, using TLS v1.2 is still considered good and secure practice by the cryptography community.

The use of TLS v1.2 ensures compatibility with a wide range of platforms and enables seamless communication between different systems that do not yet have TLS v1.3 support.

The only drawback depends on whether the framework used is outdated: its TLS v1.2 settings may enable older and insecure cipher suites that are deprecated as insecure.

On the other hand, TLS v1.3 removes support for older and weaker cryptographic algorithms, eliminates known vulnerabilities from previous TLS versions, and improves performance.

Resources

Articles & blog posts

• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

Resource-based policies granting access to all users can lead to information leakage.

Ask Yourself Whether

• The AWS resource stores or processes sensitive data.
• The AWS resource is designed to be private.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to implement the least privilege principle, i.e. to grant necessary permissions only to users for their required tasks. In the context of resource-based policies, list the principals that need the access and grant to them only the required privileges.

Sensitive Code Example

This policy allows all users, including anonymous ones, to access an S3 bucket:

resource "aws_s3_bucket_policy" "mynoncompliantpolicy" {  # Sensitive
  bucket = aws_s3_bucket.mybucket.id
  policy = jsonencode({
    Id = "mynoncompliantpolicy"
    Version = "2012-10-17"
    Statement = [{
            Effect = "Allow"
            Principal = {
                AWS = "*"
            }
            Action = [
                "s3:PutObject"
            ]
            Resource: "${aws_s3_bucket.mybucket.arn}/*"
        }
    ]
  })
}

Compliant Solution

This policy allows only the authorized users:

resource "aws_s3_bucket_policy" "mycompliantpolicy" {
  bucket = aws_s3_bucket.mybucket.id
  policy = jsonencode({
    Id = "mycompliantpolicy"
    Version = "2012-10-17"
    Statement = [{
            Effect = "Allow"
            Principal = {
                AWS = [
                    "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
                ]
            }
            Action = [
                "s3:PutObject"
            ]
            Resource = "${aws_s3_bucket.mybucket.arn}/*"
        }
    ]
  })
}

See

• AWS Documentation - Grant least privilege
• CWE - CWE-732 - Incorrect Permission Assignment for Critical Resource
• CWE - CWE-284 - Improper Access Control

Amazon Elastic Block Store (EBS) is a block-storage service for Amazon Elastic Compute Cloud (EC2). EBS volumes can be encrypted, ensuring the security of both data-at-rest and data-in-transit between an instance and its attached EBS storage. In the case that adversaries gain physical access to the storage medium they are not able to access the data. Encryption can be enabled for specific volumes or for all new volumes and snapshots. Volumes created from snapshots inherit their encryption configuration. A volume created from an encrypted snapshot will also be encrypted by default.

Ask Yourself Whether

• The disk contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt EBS volumes that contain sensitive information. Encryption and decryption are handled transparently by EC2, so no further modifications to the application are necessary. Instead of enabling encryption for every volume, it is also possible to enable encryption globally for a specific region. While creating volumes from encrypted snapshots will result in them being encrypted, explicitly enabling this security parameter will prevent any future unexpected security downgrade.

Sensitive Code Example

For aws_ebs_volume:

resource "aws_ebs_volume" "ebs_volume" {  # Sensitive as encryption is disabled by default
}

resource "aws_ebs_volume" "ebs_volume" {
  encrypted = false  # Sensitive
}

For aws_ebs_encryption_by_default:

resource "aws_ebs_encryption_by_default" "default_encryption" {
  enabled = false  # Sensitive
}

For aws_launch_configuration:

resource "aws_launch_configuration" "launch_configuration" {
  root_block_device {  # Sensitive as encryption is disabled by default
  }
  ebs_block_device {  # Sensitive as encryption is disabled by default
  }
}

resource "aws_launch_configuration" "launch_configuration" {
  root_block_device {
    encrypted = false  # Sensitive
  }
  ebs_block_device {
    encrypted = false  # Sensitive
  }
}

Compliant Solution

For aws_ebs_volume:

resource "aws_ebs_volume" "ebs_volume" {
  encrypted = true
}

For aws_ebs_encryption_by_default:

resource "aws_ebs_encryption_by_default" "default_encryption" {
  enabled = true  # Optional, default is "true"
}

For aws_launch_configuration:

resource "aws_launch_configuration" "launch_configuration" {
  root_block_device {
    encrypted = true
  }
  ebs_block_device {
    encrypted = true
  }
}

See

• Amazon EBS encryption
• CWE - CWE-311 - Missing Encryption of Sensitive Data

Within IAM, identity-based policies grant permissions to users, groups, or roles, and enable specific actions to be performed on designated resources. When an identity policy inadvertently grants more privileges than intended, certain users or roles might be able to perform more actions than expected. This can lead to potential security risks, as it enables malicious users to escalate their privileges from a lower level to a higher level of access.

Why is this an issue?

AWS Identity and Access Management (IAM) is the service that defines access to AWS resources. One of the core components of IAM is the policy which, when attached to an identity or a resource, defines its permissions. Policies granting permission to an identity (a user, a group or a role) are called identity-based policies. They add the ability to an identity to perform a predefined set of actions on a list of resources.

For such policies, it is easy to define very broad permissions (by using wildcard "*" permissions for example.) This is especially true if it is not yet clear which permissions will be required for a specific workload or use case. However, it is important to limit the amount of permissions that are granted and the amount of resources to which these permissions are granted. Doing so ensures that there are no users or roles that have more permissions than they need.

If this is not done, it can potentially carry security risks in the case that an attacker gets access to one of these identities.

What is the potential impact?

AWS IAM policies that contain overly broad permissions can lead to privilege escalation by granting users more access than necessary. They may be able to perform actions beyond their intended scope.

Privilege escalation

When IAM policies are too permissive, they grant users more privileges than necessary, allowing them to perform actions that they should not be able to. This can be exploited by attackers to gain unauthorized access to sensitive resources and perform malicious activities.

For example, if an IAM policy grants a user unrestricted access to all S3 buckets in an AWS account, the user can potentially read, write, and delete any object within those buckets. If an attacker gains access to this user’s credentials, they can exploit this overly permissive policy to exfiltrate sensitive data, modify or delete critical files, or even launch further attacks within the AWS environment. This can have severe consequences, such as data breaches, service disruptions, or unauthorized access to other resources within the AWS account.

How to fix it in AWS Identity and Access Management

Code examples

In this example, the IAM policy allows an attacker to update the code of any Lambda function. An attacker can achieve privilege escalation by altering the code of a Lambda that executes with high privileges.

Noncompliant code example

resource "aws_iam_policy" "example" {
  name = "example"
  policy =<<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:UpdateFunctionCode"
            ],
            "Resource": "*"
        }
    ]
}
EOF
}

Compliant solution

The policy is narrowed such that only updates to the code of certain Lambda functions (without high privileges) are allowed.

resource "aws_iam_policy" "example" {
  name = "example"
  policy =<<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:UpdateFunctionCode"
            ],
            "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function:1"
        }
    ]
}
EOF
}

How does this work?

Principle of least privilege

When creating IAM policies, it is important to adhere to the principle of least privilege. This means that any user or role should only be granted enough permissions to perform the tasks that they are supposed to, and nothing else.

To successfully implement this, it is easier to start from nothing and gradually build up all the needed permissions. When starting from a policy with overly broad permissions which is made stricter at a later time, it can be harder to ensure that there are no gaps that might be forgotten about. In this case, it might be useful to monitor the users or roles to verify which permissions are used.

Resources

Documentation

• AWS Documentation - Policies and permissions in IAM: Grant least privilege

Articles & blog posts

• Rhino Security Labs - AWS IAM Privilege Escalation - Methods and Mitigation

Standards

• CWE - CWE-269 - Improper Privilege Management

Amazon SageMaker is a managed machine learning service in a hosted production-ready environment. To train machine learning models, SageMaker instances can process potentially sensitive data, such as personal information that should not be stored unencrypted. In the event that adversaries physically access the storage media, they cannot decrypt encrypted data.

Ask Yourself Whether

• The instance contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt SageMaker notebook instances that contain sensitive information. Encryption and decryption are handled transparently by SageMaker, so no further modifications to the application are necessary.

Sensitive Code Example

For aws_sagemaker_notebook_instance:

resource "aws_sagemaker_notebook_instance" "notebook" {  # Sensitive, encryption disabled by default
}

Compliant Solution

For aws_sagemaker_notebook_instance:

resource "aws_sagemaker_notebook_instance" "notebook" {
  kms_key_id = aws_kms_key.enc_key.key_id
}

See

• Protect Data at Rest Using Encryption
• CWE - CWE-311 - Missing Encryption of Sensitive Data

Amazon Simple Notification Service (SNS) is a managed messaging service for application-to-application (A2A) and application-to-person (A2P) communication. SNS topics allows publisher systems to fanout messages to a large number of subscriber systems. Amazon SNS allows to encrypt messages when they are received. In the case that adversaries gain physical access to the storage medium or otherwise leak a message they are not able to access the data.

Ask Yourself Whether

• The topic contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt SNS topics that contain sensitive information. Encryption and decryption are handled transparently by SNS, so no further modifications to the application are necessary.

Sensitive Code Example

For aws_sns_topic:

resource "aws_sns_topic" "topic" {  # Sensitive, encryption disabled by default
  name = "sns-unencrypted"
}

Compliant Solution

For aws_sns_topic:

resource "aws_sns_topic" "topic" {
  name = "sns-encrypted"
  kms_master_key_id = aws_kms_key.enc_key.key_id
}

See

• AWS Documentation - Encryption at rest
• Encrypting messages published to Amazon SNS with AWS KMS
• CWE - CWE-311 - Missing Encryption of Sensitive Data

By default, GCP SQL instances offer encryption in transit, with support for TLS, but insecure connections are still accepted. On an unsecured network, such as a public network, the risk of traffic being intercepted is high. When the data isn’t encrypted, an attacker can intercept it and read confidential information.

When creating a GCP SQL instance, a public IP address is automatically assigned to it and connections to the SQL instance from public networks can be authorized.

TLS is automatically used when connecting to SQL instances through:

• The Cloud SQL Auth proxy.
• The Java Socket Library.
• The built-in mechanisms in the App Engine environments.

Ask Yourself Whether

Connections are not already automatically encrypted by GCP (eg: SQL Auth proxy) and

• Connections to the SQL instance are performed on untrusted networks.
• The data stored in the SQL instance is confidential.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt all connections to the SQL instance, whether using public or private IP addresses. However, since private networks can be considered trusted, requiring TLS in this situation is usually a lower priority task.

Sensitive Code Example

resource "google_sql_database_instance" "example" { # Sensitive: tls is not required
  name             = "noncompliant-master-instance"
  database_version = "POSTGRES_11"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
  }
}

Compliant Solution

resource "google_sql_database_instance" "example" {
  name             = "compliant-master-instance"
  database_version = "POSTGRES_11"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
    ip_configuration {
      require_ssl = true
      ipv4_enabled = true
    }
  }
}

See

• CWE - CWE-311 - Missing Encryption of Sensitive Data
• CWE - CWE-319 - Cleartext Transmission of Sensitive Information
• GCP Documentation - Cloud SQL: Authorizing with SSL/TLS certificates

Granting public access to GCP resources may reduce an organization’s ability to protect itself against attacks or theft of its GCP resources.
Security incidents associated with misuse of public access include disruption of critical functions, data theft, and additional costs due to resource overload.

To be as prepared as possible in the event of a security incident, authentication combined with fine-grained permissions helps maintain the principle of defense in depth and trace incidents back to the perpetrators.

GCP also provides the ability to grant access to a large group of people:

• If public access is granted to all Google users, the impact of a data theft is the same as if public access is granted to all Internet users.
• If access is granted to a large Google group, the impact of a data theft is limited based on the size of the group.

The only thing that changes in these cases is the ability to track user access in the event of an incident.

Ask Yourself Whether

• This GCP resource is essential to the information system infrastructure.
• This GCP resource is essential to mission-critical functions.
• This GCP resource stores or processes sensitive data.
• Compliance policies require that access to this resource be authenticated.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Explicitly set access to this resource or function as private.

Sensitive Code Example

For IAM resources:

resource "google_cloudfunctions_function_iam_binding" "example" {
  members = [
    "allUsers",              # Sensitive
    "allAuthenticatedUsers", # Sensitive
  ]
}

resource "google_cloudfunctions_function_iam_member" "example" {
  member = "allAuthenticatedUsers" # Sensitive
}

For ACL resources:

resource "google_storage_bucket_access_control" "example" {
  entity = "allUsers" # Sensitive
}

resource "google_storage_bucket_acl" "example" {
  role_entity = [
    "READER:allUsers",              # Sensitive
    "READER:allAuthenticatedUsers", # Sensitive
  ]
}

For container clusters:

resource "google_container_cluster" "example" {
  private_cluster_config {
    enable_private_nodes    = false # Sensitive
    enable_private_endpoint = false # Sensitive
  }
}

Compliant Solution

For IAM resources:

resource "google_cloudfunctions_function_iam_binding" "example" {
  members = [
    "serviceAccount:${google_service_account.example.email}",
    "group:${var.example_group}"
  ]
}

resource "google_cloudfunctions_function_iam_member" "example" {
  member = "user:${var.example_user}" # Sensitive
}

For ACL resources:

resource "google_storage_bucket_access_control" "example" {
  entity = "user-${var.example_user]"
}

resource "google_storage_bucket_acl" "example" {
  role_entity = [
    "READER:user-name@example.com",
    "READER:group-admins@example.com"
  ]
}

For container clusters:

resource "google_container_cluster" "example" {
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = true
  }
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

This rule is deprecated, and will eventually be removed.

Server-side encryption (SSE) encrypts an object (not the metadata) as it is written to disk (where the S3 bucket resides) and decrypts it as it is read from disk. This doesn’t change the way the objects are accessed, as long as the user has the necessary permissions, objects are retrieved as if they were unencrypted. Thus, SSE only helps in the event of disk thefts, improper disposals of disks and other attacks on the AWS infrastructure itself.

There are three SSE options:

• Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
  • AWS manages encryption keys and the encryption itself (with AES-256) on its own.
• Server-Side Encryption with Customer Master Keys (CMKs) Stored in AWS Key Management Service (SSE-KMS)
  • AWS manages the encryption (AES-256) of objects and encryption keys provided by the AWS KMS service.
• Server-Side Encryption with Customer-Provided Keys (SSE-C)
  • AWS manages only the encryption (AES-256) of objects with encryption keys provided by the customer. AWS doesn’t store the customer’s encryption keys.

Ask Yourself Whether

• The S3 bucket stores sensitive information.
• The infrastructure needs to comply to some regulations, like HIPAA or PCI DSS, and other standards.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to use SSE. Choosing the appropriate option depends on the level of control required for the management of encryption keys.

Sensitive Code Example

Server-side encryption is not used:

resource "aws_s3_bucket" "example" { # Sensitive
  bucket = "example"
}

Compliant Solution

Server-side encryption with Amazon S3-managed keys is used for AWS provider version 3 or below:

resource "aws_s3_bucket" "example" {
  bucket = "example"

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

Server-side encryption with Amazon S3-managed keys is used for AWS provider version 4 or above:

resource "aws_s3_bucket" "example" {
  bucket = "example"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.bucket

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

See

• AWS documentation - Protecting data using server-side encryption

By default, S3 buckets can be accessed through HTTP and HTTPs protocols.

As HTTP is a clear-text protocol, it lacks the encryption of transported data, as well as the capability to build an authenticated connection. It means that a malicious actor who is able to intercept traffic from the network can read, modify or corrupt the transported content.

Ask Yourself Whether

• The S3 bucket stores sensitive information.
• The infrastructure has to comply with AWS Foundational Security Best Practices standard.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to deny all HTTP requests:

• for all objects (*) of the bucket
• for all principals (*)
• for all actions (*)

Sensitive Code Example

No secure policy is attached to this bucket:

resource "aws_s3_bucket" "mynoncompliantbucket" { # Sensitive
  bucket = "mynoncompliantbucketname"
}

A policy is defined but forces only HTTPs communication for some users:

resource "aws_s3_bucket" "mynoncompliantbucket" { # Sensitive
  bucket = "mynoncompliantbucketname"
}

resource "aws_s3_bucket_policy" "mynoncompliantbucketpolicy" {
  bucket = "mynoncompliantbucketname"

  policy = jsonencode({
    Version = "2012-10-17"
    Id      = "mynoncompliantbucketpolicy"
    Statement = [
      {
        Sid       = "HTTPSOnly"
        Effect    = "Deny"
        Principal = [
          "arn:aws:iam::123456789123:root"
        ] # secondary location: only one principal is forced to use https
        Action    = "s3:*"
        Resource = [
          aws_s3_bucket.mynoncompliantbucketpolicy.arn,
          "${aws_s3_bucket.mynoncompliantbucketpolicy.arn}/*",
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      },
    ]
  })
}

Compliant Solution

A secure policy that denies all HTTP requests is used:

resource "aws_s3_bucket" "mycompliantbucket" {
  bucket = "mycompliantbucketname"
}

resource "aws_s3_bucket_policy" "mycompliantpolicy" {
  bucket = "mycompliantbucketname"

  policy = jsonencode({
    Version = "2012-10-17"
    Id      = "mycompliantpolicy"
    Statement = [
      {
        Sid       = "HTTPSOnly"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:*"
        Resource = [
          aws_s3_bucket.mycompliantbucket.arn,
          "${aws_s3_bucket.mycompliantbucket.arn}/*",
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      },
    ]
  })
}

See

• AWS documentation - Enforce encryption of data in transit
• AWS Foundational Security Best Practices controls - S3 buckets should require requests to use Secure Socket Layer
• CWE - CWE-319 - Cleartext Transmission of Sensitive Information

Enabling public network access to cloud resources can affect an organization’s ability to protect its data or internal operations from data theft or disruption.

Depending on the component, inbound access from the Internet can be enabled via:

• a boolean value that explicitly allows access to the public network.
• the assignment of a public IP address.
• database firewall rules that allow public IP ranges.

Deciding to allow public access may happen for various reasons such as for quick maintenance, time saving, or by accident.

This decision increases the likelihood of attacks on the organization, such as:

• data breaches.
• intrusions into the infrastructure to permanently steal from it.
• and various malicious traffic, such as DDoS attacks.

Ask Yourself Whether

This cloud resource:

• should be publicly accessible to any Internet user.
• requires inbound traffic from the Internet to function properly.

There is a risk if you answered no to any of those questions.

Recommended Secure Coding Practices

Avoid publishing cloud services on the Internet unless they are intended to be publicly accessible, such as customer portals or e-commerce sites.

Use private networks (and associated private IP addresses) and VPC peering or other secure communication tunnels to communicate with other cloud components.

The goal is to prevent the component from intercepting traffic coming in via the public IP address. If the cloud resource does not support the absence of a public IP address, assign a public IP address to it, but do not create listeners for the public IP address.

Sensitive Code Example

For AWS:

resource "aws_instance" "example" {
  associate_public_ip_address = true # Sensitive
}

resource "aws_dms_replication_instance" "example" {
  publicly_accessible = true # Sensitive
}

For Azure:

resource "azurerm_postgresql_server" "example"  {
  public_network_access_enabled = true # Sensitive
}

resource "azurerm_postgresql_server" "example"  {
  public_network_access_enabled = true # Sensitive
}

resource "azurerm_kubernetes_cluster" "production" {
  api_server_authorized_ip_ranges = ["176.0.0.0/4"] # Sensitive
  default_node_pool {
    enable_node_public_ip = true # Sensitive
  }
}

For GCP:

resource "google_compute_instance" "example" {
  network_interface {
    network = "default"

    access_config {  # Sensitive
      # Ephemeral public IP
    }
  }

Compliant Solution

For AWS:

resource "aws_instance" "example" {
  associate_public_ip_address = false
}

resource "aws_dms_replication_instance" "example" {
  publicly_accessible          = false
}

For Azure:

resource "azurerm_postgresql_server" "example"  {
  public_network_access_enabled = false
}

resource "azurerm_kubernetes_cluster" "production" {
  api_server_authorized_ip_ranges = ["192.168.0.0/16"]
  default_node_pool {
    enable_node_public_ip = false
  }
}

For GCP:

resource "google_compute_instance" "example" {
  network_interface {
    network = google_compute_network.vpc_network_example.name
  }
}

Note that setting network="default" in the network interface block leads to other security problems such as removal of logging, Cloud VPN/VPC network peering, and the addition of insecure firewall rules.
A safer alternative includes creating a specific VPC or subnetwork and enforce security measures.

See

• AWS Documentation - Amazon EC2 instance IP addressing
• AWS Documentation - Public and private replication instances
• AWS Documentation - VPC Peering
• CWE - CWE-284 - Improper Access Control
• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Granting highly privileged resource rights to users or groups can reduce an organization’s ability to protect against account or service theft. It prevents proper segregation of duties and creates potentially critical attack vectors on affected resources.

If elevated access rights are abused or compromised, both the data that the affected resources work with and their access tracking are at risk.

Ask Yourself Whether

• This GCP resource is essential to the information system infrastructure.
• This GCP resource is essential to mission-critical functions.
• Compliance policies require that administrative privileges for this resource be limited to a small group of individuals.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Grant IAM policies or members a less permissive role: In most cases, granting them read-only privileges is sufficient.

Separate tasks by creating multiple roles that do not use a full access role for day-to-day work.

If the predefined GCP roles do not include the specific permissions you need, create custom IAM roles.

Sensitive Code Example

For an IAM policy setup:

data "google_iam_policy" "admin" {
  binding {
    role = "roles/run.admin" # Sensitive
    members = [
      "user:name@example.com",
    ]
  }
}

resource "google_cloud_run_service_iam_policy" "policy" {
  location = google_cloud_run_service.default.location
  project = google_cloud_run_service.default.project
  service = google_cloud_run_service.default.name
  policy_data = data.google_iam_policy.admin.policy_data
}

For an IAM policy binding:

resource "google_cloud_run_service_iam_binding" "example" {
  location = google_cloud_run_service.default.location
  project = google_cloud_run_service.default.project
  service = google_cloud_run_service.default.name
  role = "roles/run.admin" # Sensitive
  members = [
    "user:name@example.com",
  ]
}

For adding a member to a policy:

resource "google_cloud_run_service_iam_member" "example" {
  location = google_cloud_run_service.default.location
  project = google_cloud_run_service.default.project
  service = google_cloud_run_service.default.name
  role = "roles/run.admin" # Sensitive
  member = "user:name@example.com"
}

Compliant Solution

For an IAM policy setup:

data "google_iam_policy" "admin" {
  binding {
    role = "roles/viewer"
    members = [
      "user:name@example.com",
    ]
  }
}

resource "google_cloud_run_service_iam_policy" "example" {
  location = google_cloud_run_service.default.location
  project = google_cloud_run_service.default.project
  service = google_cloud_run_service.default.name
  policy_data = data.google_iam_policy.admin.policy_data
}

For an IAM policy binding:

resource "google_cloud_run_service_iam_binding" "example" {
  location = google_cloud_run_service.default.location
  project = google_cloud_run_service.default.project
  service = google_cloud_run_service.default.name
  role = "roles/viewer"
  members = [
    "user:name@example.com",
  ]
}

For adding a member to a policy:

resource "google_cloud_run_service_iam_member" "example" {
  location = google_cloud_run_service.default.location
  project = google_cloud_run_service.default.project
  service = google_cloud_run_service.default.name
  role = "roles/viewer"
  member = "user:name@example.com"
}

See

• CWE - CWE-284 - Improper Access Control

SSH keys stored and managed in a project’s metadata can be used to access GCP VM instances. By default, GCP automatically deploys project-level SSH keys to VM instances.

Project-level SSH keys can lead to unauthorized access because:

• Their use prevents fine-grained VM-level access control and makes it difficult to follow the principle of least privilege.
• Unlike managed access control with OS Login, manual cryptographic key management is error-prone and requires careful attention. For example, if a user leaves a project, their SSH keys should be removed from the metadata to prevent unwanted access.
• If a project-level SSH key is compromised, all VM instances may be compromised.

Ask Yourself Whether

• VM instances in a project have different security requirements.
• Many users with different profiles need access to the VM instances in that project.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Block project-level SSH keys by setting the metadata.block-project-ssh-keys argument to true
• Use OSLogin to benefit from managed access control.

Sensitive Code Example

resource "google_compute_instance" "example" { # Sensitive, because metadata.block-project-ssh-keys is not set to true
  name         = "example"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  network_interface {
    network = "default"

    access_config {
    }
  }
}

Compliant Solution

resource "google_compute_instance" "example" {
  name         = "example"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  metadata = {
    block-project-ssh-keys = true
  }

  network_interface {
    network = "default"

    access_config {
    }
  }
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• CWE - CWE-269 - Improper Privilege Management
• CWE - CWE-272 - Least Privilege Violation
• GCP Documentation - Restrict SSH keys from VMs
• GCP Documentation - Risks of manual key management

Excessive granting of GCP IAM permissions can allow attackers to exploit an organization’s cloud resources with malicious intent.

To prevent improper creation or deletion of resources after an account is compromised, proactive measures include both following GCP Security Insights and ensuring custom roles contain as few privileges as possible.

After gaining a foothold in the target infrastructure, sophisticated attacks typically consist of two major parts.
First, attackers must deploy new resources to carry out their malicious intent. To guard against this, operations teams must control what unexpectedly appears in the infrastructure, such as what is:

• added
• written down
• updated
• started
• appended
• applied
• accessed.

Once the malicious intent is executed, attackers must avoid detection at all costs.
To counter attackers' attempts to remove their fingerprints, operations teams must control what unexpectedly disappears from the infrastructure, such as what is:

• stopped
• disabled
• canceled
• deleted
• destroyed
• detached
• disconnected
• suspended
• rejected
• removed.

For operations teams to be resilient in this scenario, their organization must apply both:

• Detection security: log these actions to better detect malicious actions.
• Preventive security: review and limit granted permissions.

This rule raises an issue when a custom role grants a number of sensitive permissions (read-write or destructive permission) that is greater than a given parameter.

Ask Yourself Whether

• This custom role will be mostly used for read-only purposes.
• Compliance policies require read-only access.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

To reduce the risks associated with this role after a compromise:

• Reduce the list of permissions to grant only those that are actually needed.
• Favor read-only over read-write.

Sensitive Code Example

This custom role grants more than 5 sensitive permissions:

resource "google_project_iam_custom_role" "example" {
  permissions = [ # Sensitive
    "resourcemanager.projects.create", # Sensitive permission
    "resourcemanager.projects.delete", # Sensitive permission
    "resourcemanager.projects.get",
    "resourcemanager.projects.list",
    "run.services.create", # Sensitive permission
    "run.services.delete", # Sensitive permission
    "run.services.get",
    "run.services.getIamPolicy",
    "run.services.setIamPolicy",  # Sensitive permission
    "run.services.list",
    "run.services.update",  # Sensitive permission
  ]
}

Compliant Solution

This custom role grants less than 5 sensitive permissions:

resource "google_project_iam_custom_role" "example" {
  permissions = [
    "resourcemanager.projects.get",
    "resourcemanager.projects.list",
    "run.services.create",
    "run.services.delete",
    "run.services.get",
    "run.services.getIamPolicy",
    "run.services.list",
    "run.services.update",
  ]
}

See

• GCP Docs - Enforce least privilege with role recommendations
• GCP Docs - Security Insights
• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

By default S3 buckets are private, it means that only the bucket owner can access it.

This access control can be relaxed with ACLs or policies.

To prevent permissive policies to be set on a S3 bucket the following settings can be configured:

• BlockPublicAcls: to block or not public ACLs to be set to the S3 bucket.
• IgnorePublicAcls: to consider or not existing public ACLs set to the S3 bucket.
• BlockPublicPolicy: to block or not public policies to be set to the S3 bucket.
• RestrictPublicBuckets: to restrict or not the access to the S3 endpoints of public policies to the principals within the bucket owner account.

Ask Yourself Whether

• The S3 bucket stores sensitive data.
• The S3 bucket is not used to store static resources of websites (images, css …​).
• Many users have the permission to set ACL or policy to the S3 bucket.
• These settings are not already enforced to true at the account level.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to configure:

• BlockPublicAcls to true to block new attempts to set public ACLs.
• IgnorePublicAcls to true to block existing public ACLs.
• BlockPublicPolicy to true to block new attempts to set public policies.
• RestrictPublicBuckets to true to restrict existing public policies.

Sensitive Code Example

By default, when not set, the aws_s3_bucket_public_access_block is fully deactivated (nothing is blocked):

resource "aws_s3_bucket" "example" { # Sensitive: no Public Access Block defined for this bucket
  bucket = "example"
}

This aws_s3_bucket_public_access_block allows public ACL to be set:

resource "aws_s3_bucket" "example" {  # Sensitive
  bucket = "examplename"
}

resource "aws_s3_bucket_public_access_block" "example-public-access-block" {
  bucket = aws_s3_bucket.example.id

  block_public_acls       = false # should be true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Compliant Solution

This aws_s3_bucket_public_access_block blocks public ACLs and policies, ignores existing public ACLs and restricts existing public policies:

resource "aws_s3_bucket" "example" {
  bucket = "example"
}

resource "aws_s3_bucket_public_access_block" "example-public-access-block" {
  bucket = aws_s3_bucket.example.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

See

• AWS Documentation - Blocking public access to your Amazon S3 storage
• CWE - CWE-284 - Improper Access Control

Why is this an issue?

Cloud platforms such as AWS, Azure, or GCP support virtual firewalls that can be used to restrict access to services by controlling inbound and outbound traffic.
Any firewall rule allowing traffic from all IP addresses to standard network ports on which administration services traditionally listen, such as 22 for SSH, can expose these services to exploits and unauthorized access.

What is the potential impact?

Like any other service, administration services can contain vulnerabilities. Administration services run with elevated privileges and thus a vulnerability could have a high impact on the system.

Additionally, credentials might be leaked through phishing or similar techniques. Attackers who are able to reach the services could use the credentials to log in to the system.

How to fix it

It is recommended to restrict access to remote administration services to only trusted IP addresses. In practice, trusted IP addresses are those held by system administrators or those of bastion-like servers.

Code examples

Noncompliant code example

An ingress rule allowing all inbound SSH traffic for AWS:

resource "aws_security_group" "noncompliant" {
  name        = "allow_ssh_noncompliant"
  description = "allow_ssh_noncompliant"
  vpc_id      = aws_vpc.main.id

  ingress {
    description      = "SSH rule"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = ["0.0.0.0/0"]  # Noncompliant
  }
}

A security rule allowing all inbound SSH traffic for Azure:

resource "azurerm_network_security_rule" "noncompliant" {
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "22"
  source_address_prefix       = "*"  # Noncompliant
  destination_address_prefix  = "*"
}

A firewall rule allowing all inbound SSH traffic for GCP:

resource "google_compute_firewall" "noncompliant" {
  network = google_compute_network.default.name

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["0.0.0.0/0"]  # Noncompliant
}

Compliant solution

An ingress rule allowing inbound SSH traffic from specific IP addresses for AWS:

resource "aws_security_group" "compliant" {
  name        = "allow_ssh_compliant"
  description = "allow_ssh_compliant"
  vpc_id      = aws_vpc.main.id

  ingress {
    description      = "SSH rule"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = ["1.2.3.0/24"]
  }
}

A security rule allowing inbound SSH traffic from specific IP addresses for Azure:

resource "azurerm_network_security_rule" "compliant" {
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "22"
  source_address_prefix       = "1.2.3.0"
  destination_address_prefix  = "*"
}

A firewall rule allowing inbound SSH traffic from specific IP addresses for GCP:

resource "google_compute_firewall" "compliant" {
  network = google_compute_network.default.name

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["10.0.0.1/32"]
}

Resources

Documentation

• AWS Documentation - Security groups for your VPC
• Azure Documentation - Network security groups
• GCP Documentation - Firewalls

Standards

• CWE - CWE-284 - Improper Access Control

Reducing the backup retention duration can reduce an organization’s ability to re-establish service in case of a security incident.

Data backups allow to overcome corruption or unavailability of data by recovering as efficiently as possible from a security incident.

Backup retention duration, coverage, and backup locations are essential criteria regarding functional continuity.

Ask Yourself Whether

• This component is essential for the information system infrastructure.
• This component is essential for mission-critical functions.
• Compliance policies require this component to be backed up for a specific amount of time.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Increase the backup retention period to an amount of time sufficient enough to be able to restore service in case of an incident.

Sensitive Code Example

For Amazon Relational Database Service clusters and instances:

resource "aws_db_instance" "example" {
  backup_retention_period = 2 # Sensitive
}

For Azure Cosmos DB accounts:

resource "azurerm_cosmosdb_account" "example" {
  backup {
    type = "Periodic"
    retention_in_hours = 8 # Sensitive
  }
}

Compliant Solution

For Amazon Relational Database Service clusters and instances:

resource "aws_db_instance" "example" {
  backup_retention_period = 5
}

For Azure Cosmos DB accounts:

resource "azurerm_cosmosdb_account" "example" {
  backup {
    type = "Periodic"
    retention_in_hours = 300
  }
}

The likelihood of security incidents increases when cryptographic keys are used for a long time. Thus, to strengthen the data protection it’s recommended to rotate the symmetric keys created with the Google Cloud Key Management Service (KMS) automatically and periodically. Note that it’s not possible in GCP KMS to rotate asymmetric keys automatically.

Ask Yourself Whether

• The cryptographic key is a symmetric key.
• The application requires compliance with some security standards like PCI-DSS.

Recommended Secure Coding Practices

It’s recommended to rotate keys automatically and regularly. The shorter the key period, the less data can be decrypted by an attacker if a key is compromised. So the key rotation period usually depends on the amount of data encrypted with a key or other requirements such as compliance with security standards. In general, a period of time of 90 days can be used.

Sensitive Code Example

resource "google_kms_crypto_key" "noncompliant-key" { # Sensitive: no rotation period is defined
  name            = "example"
  key_ring        = google_kms_key_ring.keyring.id
}

Compliant Solution

resource "google_kms_crypto_key" "compliant-key" {
  name            = "example"
  key_ring        = google_kms_key_ring.keyring.id
  rotation_period = "7776000s" # 90 days
}

See

• GCP Documentation - KMS Key rotation

Domain Name Systems (DNS) are vulnerable by default to various types of attacks.

One of the biggest risks is DNS cache poisoning, which occurs when a DNS accepts spoofed DNS data, caches the malicious records, and potentially sends them later in response to legitimate DNS request lookups. This attack typically relies on the attacker’s MITM ability on the network and can be used to redirect users from an intended website to a malicious website.

To prevent these vulnerabilities, Domain Name System Security Extensions (DNSSEC) ensure the integrity and authenticity of DNS data by digitally signing DNS zones.

The public key of a DNS zone used to validate signatures can be trusted as DNSSEC is based on the following chain of trust:

• The parent DNS zone adds a "fingerprint" of the public key of the child zone in a "DS record".
• The parent DNS zone signs it with its own private key.
• And this process continues until the root zone.

Ask Yourself Whether

The parent DNS zone (likely managed by the DNS registrar of the domain name) supports DNSSEC and

• The DNS zone is public (contains data such as public reachable IP addresses).

There is a risk if you answered yes to this question.

Recommended Secure Coding Practices

It’s recommended to use DNSSEC when creating private and public DNS zones.

Private DNS zones cannot be queried on the Internet and provide DNS name resolution for private networks. The risk of MITM attacks might be considered low on these networks and therefore implementing DNSSEC is still recommended but not with a high priority.

Note: Choose a robust signing algorithm when setting up DNSSEC, such as rsasha256. The insecure rsasha1 algorithm should no longer be used.

Sensitive Code Example

resource "google_dns_managed_zone" "example" { # Sensitive: dnssec_config is missing
  name     = "foobar"
  dns_name = "foo.bar."
}

Compliant Solution

resource "google_dns_managed_zone" "example" {
  name     = "foobar"
  dns_name = "foo.bar."

  dnssec_config {
    default_key_specs {
      algorithm = "rsasha256"
    }
  }
}

See

• GCP Documentation - Manage DNSSEC configuration
• CWE - CWE-345 - Insufficient Verification of Data Authenticity
• CWE - CWE-353 - Missing Support for Integrity Check

App Engine supports encryption in transit through TLS. As soon as the app is deployed, it can be requested using appspot.com domains or custom domains. By default, endpoints accept both clear-text and encrypted traffic. When communication isn’t encrypted, there is a risk that an attacker could intercept it and read confidential information.

When creating an App Engine, request handlers can be set with different security level for encryption:

• SECURE_NEVER: only HTTP requests are allowed (HTTPS requests are redirected to HTTP).
• SECURE_OPTIONAL and SECURE_DEFAULT: both HTTP and HTTPS requests are allowed.
• SECURE_ALWAYS: only HTTPS requests are allowed (HTTP requests are redirected to HTTPS).

Ask Yourself Whether

• The handler serves confidential data in HTTP responses.

There is a risk if you answered yes to this question.

Recommended Secure Coding Practices

It’s recommended for App Engine handlers to require TLS for all traffic. It can be achieved by setting the security level to SECURE_ALWAYS.

Sensitive Code Example

SECURE_DEFAULT, SECURE_NEVER and SECURE_OPTIONAL are sensitive TLS security level:

resource "google_app_engine_standard_app_version" "example" {
  version_id = "v1"
  service    = "default"
  runtime    = "nodejs"

  handlers {
    url_regex                   = ".*"
    redirect_http_response_code = "REDIRECT_HTTP_RESPONSE_CODE_301"
    security_level              = "SECURE_OPTIONAL" # Sensitive
    script {
      script_path = "auto"
    }
  }
}

Compliant Solution

Force the use of TLS for the handler by setting the security level on SECURE_ALWAYS:

resource "google_app_engine_standard_app_version" "example" {
  version_id = "v1"
  service    = "default"
  runtime    = "nodejs"

  handlers {
    url_regex                   = ".*"
    redirect_http_response_code = "REDIRECT_HTTP_RESPONSE_CODE_301"
    security_level              = "SECURE_ALWAYS"
    script {
      script_path = "auto"
    }
  }
}

See

• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• CWE - CWE-319 - Cleartext Transmission of Sensitive Information
• GCP Documentation - Overview of App Security

Creating custom roles that allow privilege escalation can allow attackers to maliciously exploit an organization’s cloud resources.

Certain GCP permissions allow impersonation of one or more privileged principals within a GCP infrastructure.
To prevent privilege escalation after an account has been compromised, proactively follow GCP Security Insights and ensure that custom roles contain as few privileges as possible that allow direct or indirect impersonation.

For example, privileges like deploymentmanager.deployments.create allow impersonation of service accounts, even if the name does not sound like it.
Other privileges like setIamPolicy, which are more explicit, directly allow their holder to extend their privileges.

After gaining a foothold in the target infrastructure, sophisticated attackers typically map their newfound roles to understand what is exploitable.

The riskiest privileges are either:

• At the infrastructure level: privileges to perform project, folder, or organization-wide administrative tasks.
• At the resource level: privileges to perform resource-wide administrative tasks.

In either case, the following privileges should be avoided or granted only with caution:

• ..setIamPolicy
• cloudbuilds.builds.create
• cloudfunctions.functions.create
• cloudfunctions.functions.update
• cloudscheduler.jobs.create
• composer.environments.create
• compute.instances.create
• dataflow.jobs.create
• dataproc.clusters.create
• deploymentmanager.deployments.create
• iam.roles.update
• iam.serviceAccountKeys.create
• iam.serviceAccounts.actAs
• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt
• orgpolicy.policy.set
• run.services.create
• serviceusage.apiKeys.create
• serviceusage.apiKeys.list
• storage.hmacKeys.create

Ask Yourself Whether

• This role requires impersonation to perform specific tasks with different privileges.
• This custom role is intended for a small group of administrators.

There is a risk if you answered no to these questions.

Recommended Secure Coding Practices

Use a permission that does not allow privilege escalation.

Sensitive Code Example

Lightweight custom role intended for a developer:

resource "google_organization_iam_custom_role" "example" {
  permissions = [
    "iam.serviceAccounts.getAccessToken",     # Sensitive
    "iam.serviceAccounts.getOpenIdToken",     # Sensitive
    "iam.serviceAccounts.actAs",              # Sensitive
    "iam.serviceAccounts.implicitDelegation", # Sensitive
    "resourcemanager.projects.get",
    "resourcemanager.projects.list",
    "run.services.create",
    "run.services.delete",
    "run.services.get",
    "run.services.getIamPolicy",
    "run.services.list",
    "run.services.update",
  ]
}

Lightweight custom role intended for a read-only user:

resource "google_project_iam_custom_role" "example" {
  permissions = [
    "iam.serviceAccountKeys.create",        # Sensitive
    "iam.serviceAccountKeys.get",           # Sensitive
    "deploymentmanager.deployments.create", # Sensitive
    "cloudbuild.builds.create",             # Sensitive
    "resourcemanager.projects.get",
    "resourcemanager.projects.list",
    "run.services.get",
    "run.services.getIamPolicy",
    "run.services.list",
  ]
}

Compliant Solution

Lightweight custom role intended for a developer:

resource "google_project_iam_custom_role" "example" {
  permissions = [
    "resourcemanager.projects.get",
    "resourcemanager.projects.list",
    "run.services.create",
    "run.services.delete",
    "run.services.get",
    "run.services.getIamPolicy",
    "run.services.list",
    "run.services.update",
  ]
}

Lightweight custom role intended for a read-only user:

resource "google_project_iam_custom_role" "example" {
  permissions = [
    "resourcemanager.projects.get",
    "resourcemanager.projects.list",
    "run.services.get",
    "run.services.getIamPolicy",
    "run.services.list",
  ]
}

See

• GCP IAM Docs - Support levels for permissions in custom roles
• GCP IAM Docs - Understanding IAM custom roles
• DEFONConference Youtube Video - DEF CON Safe Mode - Dylan Ayrey and Allison Donovan - Lateral Movement & Privilege Escalation in GCP
• Rhino Security Labs - Privilege Escalation in Google Cloud Platform - Part 1 (IAM)
• Rhino Security Labs - Privilege Escalation in Google Cloud Platform - Part 2 (Non-IAM)
• Praetorian - Google Cloud Platform (GCP) Service Account-based Privilege Escalation paths
• GCP Docs - Security Insights
• CWE - CWE-668 - Exposure of Resource to Wrong Sphere

Enabling Legacy Authorization, Attribute-Based Access Control (ABAC), on Google Kubernetes Engine resources can reduce an organization’s ability to protect itself against access controls being compromised.

For Kubernetes, Attribute-Based Access Control has been superseded by Role-Based Access Control. ABAC is not under active development anymore and thus should be avoided.

Ask Yourself Whether

• This resource is essential for the information system infrastructure.
• This resource is essential for mission-critical functions.
• Compliance policies require access to this resource to be enforced through the use of Role-Based Access Control.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Unless you are relying on ABAC, leave it disabled.

Sensitive Code Example

For Google Kubernetes Engine:

resource "google_container_cluster" "example" {
  enable_legacy_abac = true # Sensitive
}

Compliant Solution

For Google Kubernetes Engine:

resource "google_container_cluster" "example" {
  enable_legacy_abac = false
}

See

• CWE - CWE-668 - Exposure of Resource to Wrong Sphere
• Google Cloud Documentation - Hardening your cluster’s security

The Google Cloud audit logs service records administrative activities and accesses to Google Cloud resources of the project. It is important to enable audit logs to be able to investigate malicious activities in the event of a security incident.

Some project members may be exempted from having their activities recorded in the Google Cloud audit log service, creating a blind spot and reducing the capacity to investigate future security events.

Ask Yourself Whether

• The members exempted from having their activity logged have high privileges.
• Compliance rules require that audit log should be activated for all members.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It is recommended to have a consistent audit logging policy for all project members and therefore not to create logging exemptions for certain members.

Sensitive Code Example

resource "google_project_iam_audit_config" "example" {
  project = data.google_project.project.id
  service = "allServices"
  audit_log_config {
    log_type = "ADMIN_READ"
    exempted_members = [ # Sensitive
      "user:rogue.administrator@gmail.com",
    ]
  }
}

Compliant Solution

resource "google_project_iam_audit_config" "example" {
  project = data.google_project.project.id
  service = "allServices"
  audit_log_config {
    log_type = "ADMIN_READ"
  }
}

See

• GCP Documentation - Cloud Audit Logs overview

S3 buckets can be in three states related to versioning:

• unversioned (default one)
• enabled
• suspended

When the S3 bucket is unversioned or has versioning suspended it means that a new version of an object overwrites an existing one in the S3 bucket.

It can lead to unintentional or intentional information loss.

Ask Yourself Whether

• The bucket stores information that require high availability.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to enable S3 versioning and thus to have the possibility to retrieve and restore different versions of an object.

Sensitive Code Example

Versioning is disabled by default:

resource "aws_s3_bucket" "example" { # Sensitive
  bucket = "example"
}

Compliant Solution

Versioning is enabled for AWS provider version 4 or above:

resource "aws_s3_bucket" "example" {
  bucket = "example"
}

resource "aws_s3_bucket_versioning" "example-versioning" {
  bucket = aws_s3_bucket.example.id
  versioning_configuration {
    status = "Enabled"
  }
}

Versioning is enabled for AWS provider version 3 or below:

resource "aws_s3_bucket" "example" {
  bucket = "example"

  versioning {
    enabled = true
  }
}

See

• AWS documentation - Using versioning in S3 buckets

Disabling logging of this component can lead to missing traceability in case of a security incident.

Logging allows operational and security teams to get detailed and real-time feedback on an information system’s events. The logging coverage enables them to quickly react to events, ranging from the most benign bugs to the most impactful security incidents, such as intrusions.

Apart from security detection, logging capabilities also directly influence future digital forensic analyses. For example, detailed logging will allow investigators to establish a timeline of the actions perpetrated by an attacker.

Ask Yourself Whether

• This component is essential for the information system infrastructure.
• This component is essential for mission-critical functions.
• Compliance policies require this component to be monitored.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Enable the logging capabilities of this component. Depending on the component, new permissions might be required by the logging storage components.
You should consult the official documentation to enable logging for the impacted components. For example, AWS Application Load Balancer Access Logs require an additional bucket policy.

Sensitive Code Example

For Amazon S3 access requests:

resource "aws_s3_bucket" "example" { # Sensitive
  bucket = "example"
}

For Amazon API Gateway stages:

resource "aws_api_gateway_stage" "example" { # Sensitive
  xray_tracing_enabled = false # Sensitive
}

For Amazon MSK Broker logs:

resource "aws_msk_cluster" "example" {
  cluster_name           = "example"
  kafka_version          = "2.7.1"
  number_of_broker_nodes = 3

  logging_info {
    broker_logs { # Sensitive
      firehose {
        enabled = false
      }
      s3 {
        enabled = false
      }
    }
  }
}

For Amazon MQ Brokers:

resource "aws_mq_broker" "example" {
  logs {  # Sensitive
    audit   = false
    general = false
  }
}

For Amazon Amazon DocumentDB:

resource "aws_docdb_cluster" "example" { # Sensitive
  cluster_identifier = "example"
}

For Azure App Services:

resource "azurerm_app_service" "example" {
  logs {
    application_logs {
      file_system_level = "Off" # Sensitive
      azure_blob_storage {
        level = "Off"           # Sensitive
      }
    }
  }
}

For GCP VPC Subnetwork:

resource "google_compute_subnetwork" "example" { # Sensitive
  name          = "example"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.example.id
}

For GCP SQL Database Instance:

resource "google_sql_database_instance" "example" {
  name = "example"

  settings { # Sensitive
    tier = "db-f1-micro"
    ip_configuration {
      require_ssl  = true
      ipv4_enabled = true
    }
  }
}

For GCP Kubernetes Engine (GKE) cluster:

resource "google_container_cluster" "example" {
  name               = "example"
  logging_service    = "none" # Sensitive
}

Compliant Solution

For Amazon S3 access requests:

resource "aws_s3_bucket" "example-logs" {
  bucket = "example_logstorage"
  acl    = "log-delivery-write"
}

resource "aws_s3_bucket" "example" {
  bucket = "example"

  logging { # AWS provider <= 3
      target_bucket = aws_s3_bucket.example-logs.id
      target_prefix = "log/example"
  }
}

resource "aws_s3_bucket_logging" "example" { # AWS provider >= 4
  bucket = aws_s3_bucket.example.id

  target_bucket = aws_s3_bucket.example-logs.id
  target_prefix = "log/example"
}

For Amazon API Gateway stages:

resource "aws_api_gateway_stage" "example" {
  xray_tracing_enabled = true

  access_log_settings {
    destination_arn = "arn:aws:logs:eu-west-1:123456789:example"
    format = "..."
  }
}

For Amazon MSK Broker logs:

resource "aws_msk_cluster" "example" {
  cluster_name           = "example"
  kafka_version          = "2.7.1"
  number_of_broker_nodes = 3

  logging_info {
    broker_logs {
      firehose   {
        enabled = false
      }
      s3 {
        enabled = true
        bucket  = "example"
        prefix  = "log/msk-"
      }
    }
  }
}

For Amazon MQ Brokers, enable audit or general:

resource "aws_mq_broker" "example" {
  logs {
    audit   = true
    general = true
  }
}

For Amazon Amazon DocumentDB:

resource "aws_docdb_cluster" "example" {
  cluster_identifier              = "example"
  enabled_cloudwatch_logs_exports = ["audit"]
}

For Azure App Services:

resource "azurerm_app_service" "example" {
 logs {
    http_logs {
      file_system {
        retention_in_days = 90
        retention_in_mb   = 100
      }
    }

 application_logs {
      file_system_level = "Error"
      azure_blob_storage {
        retention_in_days = 90
        level             = "Error"
      }
    }
  }
}

For GCP VPC Subnetwork:

resource "google_compute_subnetwork" "example" {
  name          = "example"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.example.id

  log_config {
    aggregation_interval = "INTERVAL_10_MIN"
    flow_sampling        = 0.5
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

For GCP SQL Database Instance:

resource "google_sql_database_instance" "example" {
  name             = "example"

  settings {
    ip_configuration {
      require_ssl  = true
      ipv4_enabled = true
    }
    database_flags {
      name  = "log_connections"
      value = "on"
    }
    database_flags {
      name  = "log_disconnections"
      value = "on"
    }
    database_flags {
      name  = "log_checkpoints"
      value = "on"
    }
    database_flags {
      name  = "log_lock_waits"
      value = "on"
    }
  }
}

For GCP Kubernetes Engine (GKE) cluster:

resource "google_container_cluster" "example" {
  name               = "example"
  logging_service    = "logging.googleapis.com/kubernetes"
}

See

• AWS Documentation - Logging requests using server access logging
• CWE - CWE-778 - Insufficient Logging

Amazon Simple Queue Service (SQS) is a managed message queuing service for application-to-application (A2A) communication. Amazon SQS can store messages encrypted as soon as they are received. In the case that adversaries gain physical access to the storage medium or otherwise leak a message from the file system, for example through a vulnerability in the service, they are not able to access the data.

Ask Yourself Whether

• The queue contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt SQS queues that contain sensitive information. Encryption and decryption are handled transparently by SQS, so no further modifications to the application are necessary.

Sensitive Code Example

For aws_sqs_queue:

resource "aws_sqs_queue" "queue" {  # Sensitive, encryption disabled by default
  name = "sqs-unencrypted"
}

Compliant Solution

For aws_sqs_queue:

resource "aws_sqs_queue" "queue" {
  name = "sqs-encrypted"
  kms_master_key_id = aws_kms_key.enc_key.key_id
}

See

• AWS Documentation - Encryption at rest
• CWE - CWE-311 - Missing Encryption of Sensitive Data

Creating APIs without authentication unnecessarily increases the attack surface on the target infrastructure.

Unless another authentication method is used, attackers have the opportunity to attempt attacks against the underlying API.
This means attacks both on the functionality provided by the API and its infrastructure.

Ask Yourself Whether

• The underlying API exposes all of its contents to any anonymous Internet user.

There is a risk if you answered yes to this question.

Recommended Secure Coding Practices

In general, prefer limiting API access to a specific set of people or entities.

AWS provides multiple methods to do so:

• AWS_IAM, to use standard AWS IAM roles and policies.
• COGNITO_USER_POOLS, to use customizable OpenID Connect (OIDC) identity providers (IdP).
• CUSTOM, to use an AWS-independant OIDC provider, glued to the infrastructure with a Lambda authorizer.

Sensitive Code Example

A public API that doesn’t have access control implemented:

resource "aws_api_gateway_method" "noncompliantapi" {
  authorization = "NONE" # Sensitive
  http_method   = "GET"
}

Compliant Solution

An API that implements AWS IAM permissions:

resource "aws_api_gateway_method" "compliantapi" {
  authorization = "AWS_IAM"
  http_method   = "GET"
}

See

• AWS Documentation - Controlling and managing access to a REST API in API Gateway
• CWE - CWE-284 - Improper Access Control

Disabling Managed Identities can reduce an organization’s ability to protect itself against configuration faults and credential leaks.

Authenticating via managed identities to an Azure resource solely relies on an API call with a non-secret token. The process is inner to Azure: secrets used by Azure are not even accessible to end-users.

In typical scenarios without managed identities, the use of credentials can lead to mistakenly leaving them in code bases. In addition, configuration faults may also happen when storing these values or assigning them permissions.

By transparently taking care of the Azure Active Directory authentication, Managed Identities allow getting rid of day-to-day credentials management.

Ask Yourself Whether

The resource:

• Needs to authenticate to Azure resources that support Azure Active Directory (AAD).
• Uses a different Access Control system that doesn’t guarantee the same security controls as AAD, or no Access Control system at all.

There is a risk if you answered yes to all of those questions.

Recommended Secure Coding Practices

Enable the Managed Identities capabilities of this Azure resource. If supported, use a System-Assigned managed identity, as:

• It cannot be shared across resources.
• Its life cycle is deeply tied to the life cycle of its Azure resource.
• It provides a unique independent identity.

Alternatively, User-Assigned Managed Identities can also be used but don’t guarantee the properties listed above.

Sensitive Code Example

For Typical identity blocks:

resource "azurerm_api_management" "example" { # Sensitive, the identity block is missing
  name           = "example"
  publisher_name = "company"
}

For connections between Kusto Clusters and Azure Data Factory:

resource "azurerm_data_factory_linked_service_kusto" "example" {
  name                 = "example"
  use_managed_identity = false # Sensitive
}

Compliant Solution

For Typical identity blocks:

resource "azurerm_api_management" "example" {
  name           = "example"
  publisher_name = "company"

  identity {
    type = "SystemAssigned"
  }
}

For connections between Kusto Clusters and Azure Data Factory:

resource "azurerm_data_factory_linked_service_kusto" "example" {
  name                 = "example"
  use_managed_identity = true
}

See

• Azure AD Documentation - Managed Identities Overview
• Azure AD Documentation - Managed Identities Best Practices
• Azure AD Documentation - Services that support managed identities

Enabling Azure resource-specific admin accounts can reduce an organization’s ability to protect itself against account or service account thefts.

Full Administrator permissions fail to correctly separate duties and create potentially critical attack vectors on the impacted resources.

In case of abuse of elevated permissions, both the data on which impacted resources operate and their access traceability are at risk.

Ask Yourself Whether

• This Azure resource is essential for the information system infrastructure.
• This Azure resource is essential for mission-critical functions.
• Compliance policies require this resource to disable its administrative accounts or permissions.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Disable the administrative accounts or permissions in this Azure resource.

Sensitive Code Example

For Azure Batch Pools:

resource "azurerm_batch_pool" "example" {
  name = "sensitive"

  start_task {
    user_identity {
      auto_user {
        elevation_level = "Admin" # Sensitive
        scope = "Task"
      }
    }
  }
}

For Azure Container Registries:

resource "azurerm_container_registry" "example" {
  name = "example"
  admin_enabled = true # Sensitive
}

Compliant Solution

For Azure Batch Pools:

resource "azurerm_batch_pool" "example" {
  name = "example"

  start_task {
    user_identity {
      auto_user {
        elevation_level = "NonAdmin"
        scope = "Task"
      }
    }
  }
}

For Azure Container Registries:

resource "azurerm_container_registry" "exemple" {
  name = "example"
  admin_enabled = false
}

See

• CWE - CWE-284 - Improper Access Control

The TLS configuration of Google Cloud load balancers is defined through SSL policies.

Why is this an issue?

There are three managed profiles to choose from: COMPATIBLE (default), MODERN and RESTRICTED:

• The RESTRICTED profile supports a reduced set of cryptographic algorithms, intended to meet stricter compliance requirements.
• The MODERN profile supports a wider set of cryptographic algorithms, allowing most modern clients to negotiate TLS.
• The COMPATIBLE profile supports the widest set of cryptographic algorithms, allowing connections from older client applications.

The MODERN and COMPATIBLE profiles allow the use of older cryptographic algorithms that are no longer considered secure and are susceptible to attack.

What is the potential impact?

An attacker may be able to force the use of the insecure cryptographic algorithms, downgrading the security of the connection. This allows them to compromise the confidentiality or integrity of the data being transmitted.

The MODERN profile allows the use of the insecure SHA-1 signing algorithm. An attacker is able to generate forged data that passes a signature check, appearing to be legitimate data.

The COMPATIBLE profile additionally allows the user of key exchange algorithms that do not support forward secrecy as a feature. If the server’s private key is leaked, it can be used to decrypt all network traffic sent to and from that server.

How to fix it

Code examples

Noncompliant code example

resource "google_compute_ssl_policy" "example" {
  name            = "example"
  min_tls_version = "TLS_1_2"
  profile         = "COMPATIBLE" # Noncompliant
}

Compliant solution

resource "google_compute_ssl_policy" "example" {
  name            = "example"
  min_tls_version = "TLS_1_2"
  profile         = "RESTRICTED"
}

How does this work?

If an attacker is able to intercept and modify network traffic, they can filter the list of algorithms sent between the client and the server. By removing all secure algorithms from the list, the attacker can force the use of any insecure algorithms that remain.

The RESTRICTED profile only allows strong cryptographic algorithms to be used. There are no insecure algorithms that can compromise the security of the connection.

Pitfalls

Older client applications may not support the algorithms required by the RESTRICTED profile. These applications will no longer be able to connect.

If the MODERN or COMPATIBLE profiles must be used so that older clients can connect, consider using additional measures such as TLS client certificates or IP allow-lists to improve security.

Resources

Standards

• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

External coding guidelines

• SSL Labs - SSL and TLS Deployment Best Practices - Use Secure Cipher Suites
• Google - Google Cloud Load Balancing - Defining an SSL policy

When object versioning for Google Cloud Storage (GCS) buckets is enabled, different versions of an object are stored in the bucket, preventing accidental deletion. A specific version can always be deleted when the generation number of an object version is specified in the request.

Object versioning cannot be enabled on a bucket with a retention policy. A retention policy ensures that an object is retained for a specific period of time even if a request is made to delete or replace it. Thus, a retention policy locks the single current version of an object in the bucket, which differs from object versioning where different versions of an object are retained.

Ask Yourself Whether

• The bucket stores information that require high availability.

There is a risk if you answered yes to this question.

Recommended Secure Coding Practices

It’s recommended to enable GCS bucket versioning and thus to have the possibility to retrieve and restore different versions of an object.

Sensitive Code Example

Versioning is disabled by default:

resource "google_storage_bucket" "example" { # Sensitive
  name          = "example"
  location      = "US"
}

Compliant Solution

Versioning is enabled:

resource "google_storage_bucket" "example" {
  name          = "example"
  location      = "US"

  versioning {
    enabled = "true"
  }
}

See

• GCP documentation - Object Versioning

Defining a short log retention duration can reduce an organization’s ability to backtrace the actions of malicious actors in case of a security incident.

Logging allows operational and security teams to get detailed and real-time feedback on an information system’s events. The logging coverage enables them to quickly react to events, ranging from the most benign bugs to the most impactful security incidents, such as intrusions.

Apart from security detection, logging capabilities also directly influence future digital forensic analyses. For example, detailed logging will allow investigators to establish a timeline of the actions perpetrated by an attacker.

Ask Yourself Whether

• This component is essential for the information system infrastructure.
• This component is essential for mission-critical functions.
• Compliance policies require traceability for a longer duration.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Increase the log retention period to an amount of time sufficient enough to be able to investigate and restore service in case of an incident.

Sensitive Code Example

For AWS Cloudwatch Logs:

resource "aws_cloudwatch_log_group" "example" {
  name = "example"
  retention_in_days = 3 # Sensitive
}

For Azure Firewall Policy:

resource "azurerm_firewall_policy" "example" {
  insights {
    enabled = true
    retention_in_days = 7 # Sensitive
  }
}

For Google Cloud Logging buckets:

resource "google_logging_project_bucket_config" "example" {
    project = var.project
    location = "global"
    retention_days = 7 # Sensitive
    bucket_id = "_Default"
}

Compliant Solution

For AWS Cloudwatch Logs:

resource "aws_cloudwatch_log_group" "example" {
  name = "example"
  retention_in_days = 30
}

For Azure Firewall Policy:

resource "azurerm_firewall_policy" "example" {
  insights {
    enabled = true
    retention_in_days = 30
  }
}

For Google Cloud Logging buckets:

resource "google_logging_project_bucket_config" "example" {
    project = var.project
    location = "global"
    retention_days = 30
    bucket_id = "_Default"
}

When S3 buckets versioning is enabled it’s possible to add an additional authentication factor before being allowed to delete versions of an object or changing the versioning state of a bucket. It prevents accidental object deletion by forcing the user sending the delete request to prove that he has a valid MFA device and a corresponding valid token.

Ask Yourself Whether

• The S3 bucket stores sensitive information that is required to be preserved on the long term.
• The S3 bucket grants delete permission to many users.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to enable S3 MFA delete, note that:

• MFA delete can only be enabled with the AWS CLI or API and with the root account.
• To delete an object version, the API should be used with the x-amz-mfa header.
• The API request, with the x-amz-mfa header, can only be used in HTTPS.

Sensitive Code Example

A versioned S3 bucket does not have MFA delete enabled for AWS provider version 3 or below:

resource "aws_s3_bucket" "example" { # Sensitive
  bucket = "example"

  versioning {
    enabled = true
  }
}

A versioned S3 bucket does not have MFA delete enabled for AWS provider version 4 or above:

resource "aws_s3_bucket" "example" {
  bucket = "example"
}

resource "aws_s3_bucket_versioning" "example" { # Sensitive
  bucket = aws_s3_bucket.example.id
  versioning_configuration {
    status = "Enabled"
  }
}

Compliant Solution

MFA delete is enabled for AWS provider version 3 or below:

resource "aws_s3_bucket" "example" {
  bucket = "example"

  versioning {
    enabled = true
    mfa_delete = true
  }
}

MFA delete is enabled for AWS provider version 4 or above:

resource "aws_s3_bucket" "example" {
  bucket = "example"
}

resource "aws_s3_bucket_versioning" "example" {
  bucket = aws_s3_bucket.example.id
  versioning_configuration {
    status = "Enabled"
    mfa_delete = "Enabled"
  }
  mfa = "${var.MFA}"
}

See

• AWS documentation - Configuring MFA delete
• CWE - CWE-308 - Use of Single-factor Authentication

Amazon Elastic File System (EFS) is a serverless file system that does not require provisioning or managing storage. Stored files can be automatically encrypted by the service. In the case that adversaries gain physical access to the storage medium or otherwise leak a message they are not able to access the data.

Ask Yourself Whether

• The file system contains sensitive data that could cause harm when leaked.
• There are compliance requirements for the service to store data encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to encrypt EFS file systems that contain sensitive information. Encryption and decryption are handled transparently by EFS, so no further modifications to the application are necessary.

Sensitive Code Example

For aws_efs_file_system:

resource "aws_efs_file_system" "fs" {  # Sensitive, encryption disabled by default
}

Compliant Solution

For aws_efs_file_system:

resource "aws_efs_file_system" "fs" {
  encrypted = true
}

See

• AWS Documentation - Data encryption in Amazon EFS
• CWE - CWE-311 - Missing Encryption of Sensitive Data

Azure Active Directory offers built-in roles that can be assigned to users, groups, or service principals. Some of these roles should be carefully assigned as they grant sensitive permissions like the ability to reset passwords for all users.

An Azure account that fails to limit the use of such roles has a higher risk of being breached by a compromised owner.

This rule raises an issue when one of the following roles is assigned:

• Application Administrator
• Authentication Administrator
• Cloud Application Administrator
• Global Administrator
• Groups Administrator
• Helpdesk Administrator
• Password Administrator
• Privileged Authentication Administrator
• Privileged Role Administrator
• User Administrator

Ask Yourself Whether

• The user, group, or service principal doesn’t use the entirety of this extensive set of permissions to operate on a day-to-day basis.
• It is possible to follow the Separation of Duties principle and split permissions between multiple users, but it’s not enforced.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

• Limit the assignment of Global Administrator roles to less than five people or service principals.
• Apply the least privilege principle by choosing a role with a limited set of permissions.
• If no built-in role meets your needs, create a custom role with as few permissions as possible.

Sensitive Code Example

resource "azuread_directory_role" "example" {
  display_name = "Privileged Role Administrator" # Sensitive
}

resource "azuread_directory_role_member" "example" {
  role_object_id   = azuread_directory_role.example.object_id
  member_object_id = data.azuread_user.example.object_id
}

Compliant Solution

resource "azuread_directory_role" "example" {
  display_name = "Usage Summary Reports Reader"
}

resource "azuread_directory_role_member" "example" {
  role_object_id   = azuread_directory_role.example.object_id
  member_object_id = data.azuread_user.example.object_id
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• Azure AD Documentation - Azure AD built-in roles
• Azure AD Documentation - Best practices for Azure AD roles

When accessing a database, an empty password should be avoided as it introduces a weakness.

Why is this an issue?

When a database does not require a password for authentication, it allows anyone to access and manipulate the data stored within it. Exploiting this vulnerability typically involves identifying the target database and establishing a connection to it without the need for any authentication credentials.

What is the potential impact?

Once connected, an attacker can perform various malicious actions, such as viewing, modifying, or deleting sensitive information, potentially leading to data breaches or unauthorized access to critical systems. It is crucial to address this vulnerability promptly to ensure the security and integrity of the database and the data it contains.

Unauthorized Access to Sensitive Data

When a database lacks a password for authentication, it opens the door for unauthorized individuals to gain access to sensitive data. This can include personally identifiable information (PII), financial records, intellectual property, or any other confidential information stored in the database. Without proper access controls in place, malicious actors can exploit this vulnerability to retrieve sensitive data, potentially leading to identity theft, financial loss, or reputational damage.

Compromise of System Integrity

Without a password requirement, unauthorized individuals can gain unrestricted access to a database, potentially compromising the integrity of the entire system. Attackers can inject malicious code, alter configurations, or manipulate data within the database, leading to system malfunctions, unauthorized system access, or even complete system compromise. This can disrupt business operations, cause financial losses, and expose the organization to further security risks.

Unwanted Modifications or Deletions

The absence of a password for database access allows anyone to make modifications or deletions to the data stored within it. This poses a significant risk, as unauthorized changes can lead to data corruption, loss of critical information, or the introduction of malicious content. For example, an attacker could modify financial records, tamper with customer orders, or delete important files, causing severe disruptions to business processes and potentially leading to financial and legal consequences.

Overall, the lack of a password configured to access a database poses a serious security risk, enabling unauthorized access, data breaches, system compromise, and unwanted modifications or deletions. It is essential to address this vulnerability promptly to safeguard sensitive data, maintain system integrity, and protect the organization from potential harm.

How to fix it in Core PHP

Code examples

The following code uses an empty password to connect to a MySQL database.

The vulnerability can be fixed by using a strong password retrieved from an environment variable MYSQL_SECURE_PASSWORD. This environment variable is set during deployment. It should be strong and different for each database.

Noncompliant code example

$conn = new mysqli($servername, $username, ""); // Noncompliant

Compliant solution

$password = getenv('MYSQL_SECURE_PASSWORD');
$conn = new mysqli($servername, $username, $password);

Pitfalls

Hard-coded passwords

It could be tempting to replace the empty password with a hard-coded one. Hard-coding passwords in the code can pose significant security risks. Here are a few reasons why it is not recommended:

1. Security Vulnerability: Hard-coded passwords can be easily discovered by anyone who has access to the code, such as other developers or attackers. This can lead to unauthorized access to the database and potential data breaches.
2. Lack of Flexibility: Hard-coded passwords make it difficult to change the password without modifying the code. If the password needs to be updated, it would require recompiling and redeploying the code, which can be time-consuming and error-prone.
3. Version Control Issues: Storing passwords in code can lead to version control issues. If the code is shared or stored in a version control system, the password will be visible to anyone with access to the repository, which is a security risk.

To mitigate these risks, it is recommended to use secure methods for storing and retrieving passwords, such as using environment variables, configuration files, or secure key management systems. These methods allow for better security, flexibility, and separation of sensitive information from the codebase.

Resources

Standards

• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A2 - Broken Authentication
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• CWE - CWE-521 - Weak Password Requirements

A cross-site request forgery (CSRF) attack occurs when a trusted user of a web application can be forced, by an attacker, to perform sensitive actions that he didn’t intend, such as updating his profile or sending a message, more generally anything that can change the state of the application.

The attacker can trick the user/victim to click on a link, corresponding to the privileged action, or to visit a malicious web site that embeds a hidden web request and as web browsers automatically include cookies, the actions can be authenticated and sensitive.

Ask Yourself Whether

• The web application uses cookies to authenticate users.
• There exist sensitive operations in the web application that can be performed when the user is authenticated.
• The state / resources of the web application can be modified by doing HTTP POST or HTTP DELETE requests for example.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Protection against CSRF attacks is strongly recommended:
  • to be activated by default for all unsafe HTTP methods.
  • implemented, for example, with an unguessable CSRF token
• Of course all sensitive operations should not be performed with safe HTTP methods like GET which are designed to be used only for information retrieval.

Sensitive Code Example

For Laravel VerifyCsrfToken middleware

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    protected $except = [
        'api/*'
    ]; // Sensitive; disable CSRF protection for a list of routes
}

For Symfony Forms

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class Controller extends AbstractController {

  public function action() {
    $this->createForm('', null, [
      'csrf_protection' => false, // Sensitive; disable CSRF protection for a single form
    ]);
  }
}

Compliant Solution

For Laravel VerifyCsrfToken middleware

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    protected $except = []; // Compliant
}

Remember to add @csrf blade directive to the relevant forms when removing an element from $except. Otherwise the form submission will stop working.

For Symfony Forms

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class Controller extends AbstractController {

  public function action() {
    $this->createForm('', null, []); // Compliant; CSRF protection is enabled by default
  }
}

See

• OWASP - Top 10 2021 Category A1 - Broken Access Control
• CWE - CWE-352 - Cross-Site Request Forgery (CSRF)
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• OWASP: Cross-Site Request Forgery

Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production. Debug instructions or error messages can leak detailed information about the system, like the application’s path or file names.

Ask Yourself Whether

• The code or configuration enabling the application debug features is deployed on production servers or distributed to end users.
• The application runs by default with debug features activated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Do not enable debugging features on production servers or applications distributed to end users.

Sensitive Code Example

CakePHP 1.x, 2.x:

Configure::write('debug', 1); // Sensitive: development mode
or
Configure::write('debug', 2); // Sensitive: development mode
or
Configure::write('debug', 3); // Sensitive: development mode

CakePHP 3.0:

use Cake\Core\Configure;

Configure::config('debug', true); // Sensitive: development mode

WordPress:

define( 'WP_DEBUG', true ); // Sensitive: development mode

Compliant Solution

CakePHP 1.2:

Configure::write('debug', 0); // Compliant; this is the production mode

CakePHP 3.0:

use Cake\Core\Configure;

Configure::config('debug', false); // Compliant:  "0" or "false" for CakePHP 3.x is suitable (production mode) to not leak sensitive data on the logs.

WordPress:

define( 'WP_DEBUG', false ); // Compliant

See

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• CWE - CWE-489 - Active Debug Code
• CWE - CWE-215 - Information Exposure Through Debug Information

This rule is deprecated, and will eventually be removed.

Deserializing objects is security-sensitive. For example, it has led in the past to the following vulnerabilities:

• CVE-2017-17672: vBulletin: Unserialize PHP Code Execution
• CVE-2018-1000167: Jenkins Pipeline: arbitrary code execution vulnerability

Object deserialization from an untrusted source can lead to unexpected code execution. Deserialization takes a stream of bits and turns it into an object. If the stream contains the type of object you expect, all is well. But if you’re deserializing data coming from untrusted input, and an attacker has inserted some other type of object, you’re in trouble. Why? A known attack scenario involves the creation of a serialized PHP object with crafted attributes which will modify your application’s behavior. This attack relies on PHP magic methods like __desctruct, __wakeup or __string. The attacker doesn’t necessarily need the source code of the targeted application to exploit the vulnerability, he can also rely on the presence of open-source component and use tools to craft malicious payloads.

Ask Yourself Whether

• an attacker could have tampered with the source provided to the deserialization function
• you are using an unsafe deserialization function

You are at risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

To prevent insecure deserialization, it is recommended to:

• Use safe libraries that do not allow code execution at deserialization.
• Not communicate with the outside world using serialized objects
• Limit access to the serialized source
  • if it is a file, restrict the access to it.
  • if it comes from the network, restrict who has access to the process, such as with a Firewall or by authenticating the sender first.

See

• OWASP - Deserialization of untrusted data
• OWASP - Top 10 2017 Category A8 - Insecure Deserialization
• CWE - CWE-502 - Deserialization of Untrusted Data
• Derived from FindSecBugs rule OBJECT_DESERIALIZATION

Successful Zip Bomb attacks occur when an application expands untrusted archive files without controlling the size of the expanded data, which can lead to denial of service. A Zip bomb is usually a malicious archive file of a few kilobytes of compressed data but turned into gigabytes of uncompressed data. To achieve this extreme compression ratio, attackers will compress irrelevant data (eg: a long string of repeated bytes).

Ask Yourself Whether

Archives to expand are untrusted and:

• There is no validation of the number of entries in the archive.
• There is no validation of the total size of the uncompressed data.
• There is no validation of the ratio between the compressed and uncompressed archive entry.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Define and control the ratio between compressed and uncompressed data, in general the data compression ratio for most of the legit archives is 1 to 3.
• Define and control the threshold for maximum total size of the uncompressed data.
• Count the number of file entries extracted from the archive and abort the extraction if their number is greater than a predefined threshold, in particular it’s not recommended to recursively expand archives (an entry of an archive could be also an archive).

Sensitive Code Example

For ZipArchive module:

$zip = new ZipArchive();
if ($zip->open($file) === true) {
    $zip->extractTo('.'); // Sensitive
    $zip->close();
}

For Zip module:

$zip = zip_open($file);
while ($file = zip_read($zip)) {
    $filename = zip_entry_name($file);
    $size = zip_entry_filesize($file);

    if (substr($filename, -1) !== '/') {
        $content = zip_entry_read($file, zip_entry_filesize($file)); // Sensitive - zip_entry_read() uses zip_entry_filesize()
        file_put_contents($filename, $content);
    } else {
        mkdir($filename);
    }
}
zip_close($zip);

Compliant Solution

For ZipArchive module:

define('MAX_FILES', 10000);
define('MAX_SIZE', 1000000000); // 1 GB
define('MAX_RATIO', 10);
define('READ_LENGTH', 1024);

$fileCount = 0;
$totalSize = 0;

$zip = new ZipArchive();
if ($zip->open($file) === true) {
    for ($i = 0; $i < $zip->numFiles; $i++) {
        $filename = $zip->getNameIndex($i);
        $stats = $zip->statIndex($i);

        if (strpos($filename, '../') !== false || substr($filename, 0, 1) === '/') {
            throw new Exception();
        }

        if (substr($filename, -1) !== '/') {
            $fileCount++;
            if ($fileCount > MAX_FILES) {
                // Reached max. number of files
                throw new Exception();
            }

            $fp = $zip->getStream($filename); // Compliant
            $currentSize = 0;
            while (!feof($fp)) {
                $currentSize += READ_LENGTH;
                $totalSize += READ_LENGTH;

                if ($totalSize > MAX_SIZE) {
                    // Reached max. size
                    throw new Exception();
                }

                // Additional protection: check compression ratio
                if ($stats['comp_size'] > 0) {
                    $ratio = $currentSize / $stats['comp_size'];
                    if ($ratio > MAX_RATIO) {
                        // Reached max. compression ratio
                        throw new Exception();
                    }
                }

                file_put_contents($filename, fread($fp, READ_LENGTH), FILE_APPEND);
            }

            fclose($fp);
        } else {
            mkdir($filename);
        }
    }
    $zip->close();
}

For Zip module:

define('MAX_FILES', 10000);
define('MAX_SIZE', 1000000000); // 1 GB
define('MAX_RATIO', 10);
define('READ_LENGTH', 1024);

$fileCount = 0;
$totalSize = 0;

$zip = zip_open($file);
while ($file = zip_read($zip)) {
    $filename = zip_entry_name($file);

    if (strpos($filename, '../') !== false || substr($filename, 0, 1) === '/') {
        throw new Exception();
    }

    if (substr($filename, -1) !== '/') {
        $fileCount++;
        if ($fileCount > MAX_FILES) {
            // Reached max. number of files
            throw new Exception();
        }

        $currentSize = 0;
        while ($data = zip_entry_read($file, READ_LENGTH)) { // Compliant
            $currentSize += READ_LENGTH;
            $totalSize += READ_LENGTH;

            if ($totalSize > MAX_SIZE) {
                // Reached max. size
                throw new Exception();
            }

            // Additional protection: check compression ratio
            if (zip_entry_compressedsize($file) > 0) {
                $ratio = $currentSize / zip_entry_compressedsize($file);
                if ($ratio > MAX_RATIO) {
                    // Reached max. compression ratio
                    throw new Exception();
                }
            }

            file_put_contents($filename, $data, FILE_APPEND);
        }
    } else {
        mkdir($filename);
    }
}
zip_close($zip);

See

• OWASP - Top 10 2021 Category A1 - Broken Access Control
• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A5 - Broken Access Control
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
• bamsoftware.com - A better Zip Bomb

This rule is deprecated; use S5542 instead.

Why is this an issue?

Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an issue when openssl_public_encrypt is used with one the following padding constants: OPENSSL_NO_PADDING or OPENSSL_PKCS1_PADDING or OPENSSL_SSLV23_PADDING.

Noncompliant code example

function encrypt($data, $key) {
  $crypted='';
  openssl_public_encrypt($data, $crypted, $key, OPENSSL_NO_PADDING); // Noncompliant
  return $crypted;
}

Compliant solution

function encrypt($data, $key) {
  $crypted='';
  openssl_public_encrypt($data, $crypted, $key, OPENSSL_PKCS1_OAEP_PADDING);
  return $crypted;
}

Resources

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-780 - Use of RSA Algorithm without OAEP
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• Derived from FindSecBugs rule RSA NoPadding Unsafe

This rule is deprecated; use S5547 instead.

Why is this an issue?

According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:

Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer provides the security that is needed to protect federal government information.

Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.

For similar reasons, RC2 should also be avoided.

Noncompliant code example

<?php
  $ciphertext = mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_DES_COMPAT, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_TRIPLEDES, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_3DES, $key, $plaintext, $mode); // Noncompliant

  $cipher = "des-ede3-cfb";  // Noncompliant
  $ciphertext_raw = openssl_encrypt($plaintext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
?>

Compliant solution

<?php
  $ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $plaintext, MCRYPT_MODE_CBC, $iv);
?>

Resources

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-326 - Inadequate Encryption Strength
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• Derived from FindSecBugs rule DES / DESede Unsafe

PHP session tokens are normally transmitted through HTTP cookies. However, for clients that do not support cookies and when the PHP session.use_trans_sid setting is enabled, those tokens can be transmitted as URL parameters.

Why is this an issue?

GET URL parameter can be disclosed in a variety of ways:

• Directly in a web browser address bar.
• In navigation history.
• In web servers or intermediate proxies log files.

What is the potential impact?

Attackers with access to any of those disclosure locations will be able to see and steal a victim’s session token. They can then use it to log in as the user, impersonate their account, and take advantage of their privileges.

Such an attack can be more or less severe depending on the victim’s privileges. Common security impacts range from data theft to application takeover.

Data theft

Attackers with access to a compromised account will be able to disclose any information stored on it. This includes the Personally Identifiable Information (PII) of the user.

The confidentiality of PII is a requirement from national security regulatory authorities in most countries. Insufficiently protecting this data could have legal consequences and lead to fines or other prosecutions.

Application takeover

Attackers compromise the account of a high-privileged user could modify internal web application logic, disrupt workflows, or change other application’s settings in a way that will give them full control over it.

Such an attack would lead to reputational damages and financial and legal consequences.

How to fix it

Code examples

Noncompliant code example

; php.ini
session.use_trans_sid=1  ; Noncompliant

Compliant solution

; php.ini
session.use_trans_sid=0

How does this work?

The compliant code example disables the session.use_trans_sid setting.

Note that this parameter is off by default.

Resources

Standards

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

For AES, the weakest mode is ECB (Electronic Codebook). Repeated blocks of data are encrypted to the same value, making them easy to identify and reducing the difficulty of recovering the original cleartext.

Unauthenticated modes such as CBC (Cipher Block Chaining) may be used but are prone to attacks that manipulate the ciphertext. They must be used with caution.

For RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.

What is the potential impact?

The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.

Below are some real-world scenarios that illustrate possible impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

How to fix it in Mcrypt

Code examples

Noncompliant code example

Example with a symmetric cipher, AES:

mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, "ecb"); // Noncompliant

Compliant solution

Mcrypt is deprecated and should not be used. You can use Sodium instead.

For the AES symmetric cipher, use the GCM mode:

sodium_crypto_aead_aes256gcm_encrypt($plaintext, '', $nonce, $key);

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

Appropriate choices are currently the following.

For AES: use authenticated encryption modes

The best-known authenticated encryption mode for AES is Galois/Counter mode (GCM).

GCM mode combines encryption with authentication and integrity checks using a cryptographic hash function and provides both confidentiality and authenticity of data.

Other similar modes are:

• CCM: Counter with CBC-MAC
• CWC: Cipher Block Chaining with Message Authentication Code
• EAX: Encrypt-and-Authenticate
• IAPM: Integer Authenticated Parallelizable Mode
• OCB: Offset Codebook Mode

It is also possible to use AES-CBC with HMAC for integrity checks. However, it is considered more straightforward to use AES-GCM directly instead.

For RSA: use the OAEP scheme

The Optimal Asymmetric Encryption Padding scheme (OAEP) adds randomness and a secure hash function that strengthens the regular inner workings of RSA.

Resources

Articles & blog posts

• Microsoft, Timing vulnerabilities with CBC-mode symmetric decryption using padding
• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

This vulnerability makes it possible that the cleartext of the encrypted message might be recoverable without prior knowledge of the key.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

What is the potential impact?

The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

How to fix it in Mcrypt

Code examples

The following code contains examples of algorithms that are not considered highly resistant to cryptanalysis and thus should be avoided.

Noncompliant code example

mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, $mode); // Noncompliant

Compliant solution

Mcrypt is deprecated and should not be used. You can use Sodium instead.

sodium_crypto_aead_aes256gcm_encrypt($plaintext, '', $nonce, $key);

How does this work?

Use a secure algorithm

It is highly recommended to use an algorithm that is currently considered secure by the cryptographic community. A common choice for such an algorithm is the Advanced Encryption Standard (AES).

For block ciphers, it is not recommended to use algorithms with a block size that is smaller than 128 bits.

Resources

Standards

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

Using pseudorandom number generators (PRNGs) is security-sensitive. For example, it has led in the past to the following vulnerabilities:

• CVE-2013-6386
• CVE-2006-3419
• CVE-2008-4102

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.

As the rand() and mt_rand() functions rely on a pseudorandom number generator, it should not be used for security-critical applications or for protecting sensitive data.

Ask Yourself Whether

• the code using the generated value requires it to be unpredictable. It is the case for all encryption mechanisms or when a secret value, such as a password, is hashed.
• the function you use generates a value which can be predicted (pseudo-random).
• the generated value is used multiple times.
• an attacker can access the generated value.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use functions which rely on a cryptographically strong random number generator such as random_int() or random_bytes() or openssl_random_pseudo_bytes()
• When using openssl_random_pseudo_bytes(), provide and check the crypto_strong parameter
• Use the generated random values only once.
• You should not expose the generated random value. If you have to store it, make sure that the database or file is secure.

Sensitive Code Example

$random = rand();
$random2 = mt_rand(0, 99);

Compliant Solution

$randomInt = random_int(0,99); // Compliant; generates a cryptographically secure random integer

See

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP - Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• CWE - CWE-338 - Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
• CWE - CWE-330 - Use of Insufficiently Random Values
• CWE - CWE-326 - Inadequate Encryption Strength
• CWE - CWE-1241 - Use of Predictable Algorithm in Random Number Generator
• Derived from FindSecBugs rule Predictable Pseudo Random Number Generator

File access functions in PHP are typically used to open local files. They are also capable of reading files from remote servers using protocols such as HTTP, HTTPS and FTP.

This behavior is controlled by the allow_url_fopen and allow_url_include settings.

Why is this an issue?

Most applications do not require or expect the file access functions to download remotely accessible files. However, attackers can abuse these remote file access features while exploiting other vulnerabilities, such as path traversal issues.

What is the potential impact?

While activating these settings does not pose a direct threat to the application’s security, they can make the exploitation of other vulnerabilities easier and more severe.

If an attacker can control a file location while allow_url_fopen is set to 1, they can use this ability to perform a Server-Side Request Forgery exploit. This allows the attacker to affect more than just the local application and they may be able to laterally attack other assets on the local network.

If allow_url_include is set to 1, the attacker will also have the ability to download and execute arbitrary PHP code.

How to fix it

allow_url_fopen and allow_url_include should be deactivated in the main PHP configuration file. Note that allow_url_include is disabled by default while allow_url_fopen is not and must be explicitly disabled.

Code examples

Noncompliant code example

; php.ini  Noncompliant; allow_url_fopen is enabled by default
allow_url_include=1  ; Noncompliant

Compliant solution

; php.ini
allow_url_fopen=0
allow_url_include=0

Resources

Standards

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-16 - Inclusion of Functionality from Untrusted Control Sphere

The cgi.force_redirect php.ini configuration controls the behavior of the PHP engine when used in CGI mode. In particular, it prevents CGI scripts from being directly requested without prior web server or application processing.

When disabled, CGI scripts can be requested directly.

Why is this an issue?

Pre-processing on the server side is often required to check users authentication when working in CGI mode. Those preliminary actions can also position diverse configuration parameters necessary for the CGI script to work correctly.

What is the potential impact?

CGI scripts might behave unexpectedly if the proper configuration is not set up before they are accessed.

Most serious security-related consequences will affect the authorization and authentication mechanisms of the application. When the web server is responsible for authenticating clients and forwarding the proper identity to the script, direct access will bypass this authentication step.

Attackers could also provide arbitrary identities to the CGI script by forging specific HTTP headers or parameters. They could then impersonate any legitimate user of the application.

How to fix it

cgi.force_redirect should be enforced in the main PHP configuration file.

Note that this parameter is enabled by default.

Code examples

Noncompliant code example

; php.ini
cgi.force_redirect=0  ; Noncompliant

Compliant solution

; php.ini
cgi.force_redirect=1  ; Noncompliant

Pitfalls

The cgi.force_redirect is not supported by all web servers. For example, Microsoft IIS web server is unable to differentiate an internally redirected request from a normal one.

While using such a server, the cgi.force_redirect parameter will have to be disabled for the CGI scripts to work properly. In that case, it is important to ensure the CGI behavior is aware of the security threat.

Resources

Standards

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-305 - Authentication Bypass by Primary Weakness

The enable_dl PHP configuration setting allows PHP extensions to be loaded dynamically at runtime.

Why is this an issue?

When dynamic loading is enabled, PHP code can load arbitrary PHP extensions by calling the dl function. This can be used to bypass restrictions set with the open_basedir configuration.

PHP defaults to allowing dynamic loading.

How to fix it

enable_dl setting should be set to 0 in the main PHP configuration.

Code examples

Noncompliant code example

; php.ini
enable_dl=1  ; Noncompliant

Compliant solution

; php.ini
enable_dl=0

Resources

Standards

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

To provide communication security over a network, SSL and TLS are generally used. However, it is important to note that the following protocols are all considered weak by the cryptographic community, and are officially deprecated:

• SSL versions 1.0, 2.0 and 3.0
• TLS versions 1.0 and 1.1

When these unsecured protocols are used, it is best practice to expect a breach: that a user or organization with malicious intent will perform mathematical attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in Core PHP

Code examples

Noncompliant code example

$opts = array(
  'ssl' => [
    'crypto_method' => STREAM_CRYPTO_METHOD_TLSv1_1_CLIENT // Noncompliant
  ],
  'http'=>array(
    'method'=>"GET"
  )
);

$context = stream_context_create($opts);

$fp = fopen('https://www.example.com', 'r', false, $context);
fpassthru($fp);
fclose($fp);

Compliant solution

$opts = array(
  'ssl' => [
    'crypto_method' => STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT
  ],
  'http'=>array(
    'method'=>"GET"
  )
);

$context = stream_context_create($opts);

$fp = fopen('https://www.example.com', 'r', false, $context);
fpassthru($fp);
fclose($fp);

How does this work?

As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The best choices at the moment are the following.

Use TLS v1.2 or TLS v1.3

Even though TLS V1.3 is available, using TLS v1.2 is still considered good and secure practice by the cryptography community.

The use of TLS v1.2 ensures compatibility with a wide range of platforms and enables seamless communication between different systems that do not yet have TLS v1.3 support.

The only drawback depends on whether the framework used is outdated: its TLS v1.2 settings may enable older and insecure cipher suites that are deprecated as insecure.

On the other hand, TLS v1.3 removes support for older and weaker cryptographic algorithms, eliminates known vulnerabilities from previous TLS versions, and improves performance.

Resources

Articles & blog posts

• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

This vulnerability exposes encrypted data to attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In today’s cryptography, the length of the key directly affects the security level of cryptographic algorithms.

Note that depending on the algorithm, the term key refers to a different mathematical property. For example:

• For RSA, the key is the product of two large prime numbers, also called the modulus.
• For AES and Elliptic Curve Cryptography (ECC), the key is only a sequence of randomly generated bytes.
  • In some cases, AES keys are derived from a master key or a passphrase using a Key Derivation Function (KDF) like PBKDF2 (Password-Based Key Derivation Function 2)

If an application uses a key that is considered short and insecure, the encrypted data is exposed to attacks aimed at getting at the plaintext.

In general, it is best practice to expect a breach: that a user or organization with malicious intent will perform cryptographic attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in Core PHP

Code examples

Noncompliant code example

Here is an example of a private key generation with RSA:

$config = [
    "digest_alg"       => "sha512",
    "private_key_bits" => 1024,                 // Noncompliant
    "private_key_type" => OPENSSL_KEYTYPE_RSA,
];

$res = openssl_pkey_new($config);

Compliant solution

$config = [
    "digest_alg"       => "sha512",
    "private_key_bits" => 2048,
    "private_key_type" => OPENSSL_KEYTYPE_RSA,
];

$res = openssl_pkey_new($config);

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptography community.

The appropriate choices are the following.

RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)

The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.

In general, a minimum key size of 2048 bits is recommended for both. It provides 112 bits of security. A key length of 3072 or 4092 should be preferred when possible.

AES (Advanced Encryption Standard)

AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying all possible keys.
A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible. Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.

Currently, a minimum key size of 128 bits is recommended for AES.

Elliptic Curve Cryptography (ECC)

Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve algorithms is mentioned directly in their names. For example, secp256k1 generates a 256-bits long private key.

Currently, a minimum key size of 224 bits is recommended for EC-based algorithms.

Additionally, some curves that theoretically provide sufficiently long keys are still discouraged. This can be because of a flaw in the curve parameters, a bad overall design, or poor performance. It is generally advised to use a NIST-approved elliptic curve wherever possible. Such curves currently include:

• NIST P curves with a size of at least 224 bits, e.g. secp256r1.
• Curve25519, generally known as ed25519 or x25519 depending on its application.
• Curve448.
• Brainpool curves with a size of at least 224 bits, e.g. brainpoolP224r1

Going the extra mile

Pre-Quantum Cryptography

Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.
It is important to keep in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or "post-quantum") counterpart.

Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.

Learn more here.

Resources

• Documentation
  • NIST Documentation - NIST SP 800-186: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters
  • IETF - rfc5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation

Articles & blog posts

• Microsoft, Timing vulnerabilities with CBC-mode symmetric decryption using padding
• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• OWASP - Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP - Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• NIST 800-131A - Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
• CWE - CWE-326 - Inadequate Encryption Strength
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• CERT, MSC61-J. - Do not use insecure or weak cryptographic algorithms

This rule is deprecated; use S4426, S5542, S5547 instead.

Encrypting data is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-7902
• CVE-2006-1378
• CVE-2003-1376

Proper encryption requires both the encryption algorithm and the key to be strong. Obviously the private key needs to remain secret and be renewed regularly. However these are not the only means to defeat or weaken an encryption.

This rule flags function calls that initiate encryption/decryption.

Ask Yourself Whether

• the private key might not be random, strong enough or the same key is reused for a long long time.
• the private key might be compromised. It can happen when it is stored in an unsafe place or when it was transferred in an unsafe manner.
• the key exchange is made without properly authenticating the receiver.
• the encryption algorithm is not strong enough for the level of protection required. Note that encryption algorithms strength decreases as time passes.
• the chosen encryption library is deemed unsafe.
• a nonce is used, and the same value is reused multiple times, or the nonce is not random.
• the RSA algorithm is used, and it does not incorporate an Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
• the CBC (Cypher Block Chaining) algorithm is used for encryption, and it’s IV (Initialization Vector) is not generated using a secure random algorithm, or it is reused.
• the Advanced Encryption Standard (AES) encryption algorithm is used with an unsecure mode. See the recommended practices for more information.

You are at risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Generate encryption keys using secure random algorithms.
• When generating cryptographic keys (or key pairs), it is important to use a key length that provides enough entropy against brute-force attacks. For the Blowfish algorithm the key should be at least 128 bits long, while for the RSA algorithm it should be at least 2048 bits long.
• Regenerate the keys regularly.
• Always store the keys in a safe location and transfer them only over safe channels.
• If there is an exchange of cryptographic keys, check first the identity of the receiver.
• Only use strong encryption algorithms. Check regularly that the algorithm is still deemed secure. It is also imperative that they are implemented correctly. Use only encryption libraries which are deemed secure. Do not define your own encryption algorithms as they will most probably have flaws.
• When a nonce is used, generate it randomly every time.
• When using the RSA algorithm, incorporate an Optimal Asymmetric Encryption Padding (OAEP).
• When CBC is used for encryption, the IV must be random and unpredictable. Otherwise it exposes the encrypted value to crypto-analysis attacks like "Chosen-Plaintext Attacks". Thus a secure random algorithm should be used. An IV value should be associated to one and only one encryption cycle, because the IV’s purpose is to ensure that the same plaintext encrypted twice will yield two different ciphertexts.
• The Advanced Encryption Standard (AES) encryption algorithm can be used with various modes. Galois/Counter Mode (GCM) with no padding should be preferred to the following combinations which are not secured:
  • Electronic Codebook (ECB) mode: Under a given key, any given plaintext block always gets encrypted to the same ciphertext block. Thus, it does not hide data patterns well. In some senses, it doesn’t provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.
  • Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is susceptible to padding oracle attacks.

Sensitive Code Example

Builtin functions

function myEncrypt($cipher, $key, $data, $mode, $iv, $options, $padding, $infile, $outfile, $recipcerts, $headers, $nonce, $ad, $pub_key_ids, $env_keys)
{
    mcrypt_ecb ($cipher, $key, $data, $mode); // Sensitive
    mcrypt_cfb($cipher, $key, $data, $mode, $iv); // Sensitive
    mcrypt_cbc($cipher, $key, $data, $mode, $iv); // Sensitive
    mcrypt_encrypt($cipher, $key, $data, $mode); // Sensitive

    openssl_encrypt($data, $cipher, $key, $options, $iv); // Sensitive
    openssl_public_encrypt($data, $crypted, $key, $padding); // Sensitive
    openssl_pkcs7_encrypt($infile, $outfile, $recipcerts, $headers); // Sensitive
    openssl_seal($data, $sealed_data, $env_keys, $pub_key_ids); // Sensitive

    sodium_crypto_aead_aes256gcm_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_aead_chacha20poly1305_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_aead_chacha20poly1305_ietf_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_aead_xchacha20poly1305_ietf_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_box_seal ($data, $key); // Sensitive
    sodium_crypto_box ($data, $nonce, $key); // Sensitive
    sodium_crypto_secretbox ($data, $nonce, $key); // Sensitive
    sodium_crypto_stream_xor ($data, $nonce, $key); // Sensitive
}

CakePHP

use Cake\Utility\Security;

function myCakeEncrypt($key, $data, $engine)
{
    Security::encrypt($data, $key); // Sensitive

    // Do not use custom made engines and remember that Mcrypt is deprecated.
    Security::engine($engine); // Sensitive. Setting the encryption engine.
}

CodeIgniter

class EncryptionController extends CI_Controller
{
    public function __construct()
    {
        parent::__construct();
        $this->load->library('encryption');
    }

    public function index()
    {
        $this->encryption->create_key(16); // Sensitive. Review the key length.
        $this->encryption->initialize( // Sensitive.
            array(
                'cipher' => 'aes-256',
                'mode' => 'ctr',
                'key' => 'the key',
            )
        );
        $this->encryption->encrypt("mysecretdata"); // Sensitive.
    }
}

CraftCMS version 3

use Craft;

// This is similar to Yii as it used by CraftCMS
function craftEncrypt($data, $key, $password) {
    Craft::$app->security->encryptByKey($data, $key); // Sensitive
    Craft::$app->getSecurity()->encryptByKey($data, $key); // Sensitive
    Craft::$app->security->encryptByPassword($data, $password); // Sensitive
    Craft::$app->getSecurity()->encryptByPassword($data, $password); // Sensitive
}

Drupal 7 - Encrypt module

function drupalEncrypt() {
    $encrypted_text = encrypt('some string to encrypt'); // Sensitive
}

Joomla

use Joomla\Crypt\CipherInterface;

abstract class MyCipher implements CipherInterface // Sensitive. Implementing custom cipher class
{}

function joomlaEncrypt() {
    new Joomla\Crypt\Cipher_Sodium(); // Sensitive
    new Joomla\Crypt\Cipher_Simple(); // Sensitive
    new Joomla\Crypt\Cipher_Rijndael256(); // Sensitive
    new Joomla\Crypt\Cipher_Crypto(); // Sensitive
    new Joomla\Crypt\Cipher_Blowfish(); // Sensitive
    new Joomla\Crypt\Cipher_3DES(); // Sensitive
}
}

Laravel

use Illuminate\Support\Facades\Crypt;

function myLaravelEncrypt($data)
{
    Crypt::encryptString($data); // Sensitive
    Crypt::encrypt($data); // Sensitive
    // encrypt using the Laravel "encrypt" helper
    encrypt($data); // Sensitive
}

PHP-Encryption library

use Defuse\Crypto\Crypto;
use Defuse\Crypto\File;

function mypPhpEncryption($data, $key, $password, $inputFilename, $outputFilename, $inputHandle, $outputHandle) {
    Crypto::encrypt($data, $key); // Sensitive
    Crypto::encryptWithPassword($data, $password); // Sensitive
    File::encryptFile($inputFilename, $outputFilename, $key); // Sensitive
    File::encryptFileWithPassword($inputFilename, $outputFilename, $password); // Sensitive
    File::encryptResource($inputHandle, $outputHandle, $key); // Sensitive
    File::encryptResourceWithPassword($inputHandle, $outputHandle, $password); // Sensitive
}

PhpSecLib

function myphpseclib($mode) {
    new phpseclib\Crypt\RSA(); // Sensitive. Note: RSA can also be used for signing data.
    new phpseclib\Crypt\AES(); // Sensitive
    new phpseclib\Crypt\Rijndael(); // Sensitive
    new phpseclib\Crypt\Twofish(); // Sensitive
    new phpseclib\Crypt\Blowfish(); // Sensitive
    new phpseclib\Crypt\RC4(); // Sensitive
    new phpseclib\Crypt\RC2(); // Sensitive
    new phpseclib\Crypt\TripleDES(); // Sensitive
    new phpseclib\Crypt\DES(); // Sensitive

    new phpseclib\Crypt\AES($mode); // Sensitive
    new phpseclib\Crypt\Rijndael($mode); // Sensitive
    new phpseclib\Crypt\TripleDES($mode); // Sensitive
    new phpseclib\Crypt\DES($mode); // Sensitive
}

Sodium Compat library

function mySodiumCompatEncrypt($data, $ad, $nonce, $key) {
    ParagonIE_Sodium_Compat::crypto_aead_chacha20poly1305_ietf_encrypt($data, $ad, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_aead_xchacha20poly1305_ietf_encrypt($data, $ad, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_aead_chacha20poly1305_encrypt($data, $ad, $nonce, $key); // Sensitive

    ParagonIE_Sodium_Compat::crypto_aead_aes256gcm_encrypt($data, $ad, $nonce, $key); // Sensitive

    ParagonIE_Sodium_Compat::crypto_box($data, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_secretbox($data, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_box_seal($data, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_secretbox_xchacha20poly1305($data, $nonce, $key); // Sensitive
}

Yii version 2

use Yii;

// Similar to CraftCMS as it uses Yii
function YiiEncrypt($data, $key, $password) {
    Yii::$app->security->encryptByKey($data, $key); // Sensitive
    Yii::$app->getSecurity()->encryptByKey($data, $key); // Sensitive
    Yii::$app->security->encryptByPassword($data, $password); // Sensitive
    Yii::$app->getSecurity()->encryptByPassword($data, $password); // Sensitive
}

Zend

use Zend\Crypt\FileCipher;
use Zend\Crypt\PublicKey\DiffieHellman;
use Zend\Crypt\PublicKey\Rsa;
use Zend\Crypt\Hybrid;
use Zend\Crypt\BlockCipher;

function myZendEncrypt($key, $data, $prime, $options, $generator, $lib)
{
    new FileCipher; // Sensitive. This is used to encrypt files

    new DiffieHellman($prime, $generator, $key); // Sensitive

    $rsa = Rsa::factory([ // Sensitive
        'public_key'    => 'public_key.pub',
        'private_key'   => 'private_key.pem',
        'pass_phrase'   => 'mypassphrase',
        'binary_output' => false,
    ]);
    $rsa->encrypt($data); // No issue raised here. The configuration of the Rsa object is the line to review.

    $hybrid = new Hybrid(); // Sensitive

    BlockCipher::factory($lib, $options); // Sensitive
}

See

• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-321 - Use of Hard-coded Cryptographic Key
• CWE - CWE-322 - Key Exchange without Entity Authentication
• CWE - CWE-323 - Reusing a Nonce, Key Pair in Encryption
• CWE - CWE-324 - Use of a Key Past its Expiration Date
• CWE - CWE-325 - Missing Required Cryptographic Step
• CWE - CWE-326 - Inadequate Encryption Strength
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

An attacker may trick a user into using a predetermined session identifier. Consequently, this attacker can gain unauthorized access and impersonate the user’s session. This kind of attack is called session fixation, and protections against it should not be disabled.

Why is this an issue?

Session fixation attacks take advantage of the way web applications manage session identifiers. Here’s how a session fixation attack typically works:

• When a user visits a website or logs in, a session is created for them.
• This session is assigned a unique session identifier, stored in a cookie, in local storage, or through URL parameters.
• In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. For example, the attacker sends the victim an email containing a link with this predetermined session identifier.
• When the victim clicks on the link, the web application does not create a new session identifier but uses this identifier known to the attacker.
• At this point, the attacker can hijack and impersonate the victim’s session.

What is the potential impact?

Session fixation attacks pose a significant security risk to web applications and their users. By exploiting this vulnerability, attackers can gain unauthorized access to user sessions, potentially leading to various malicious activities. Some of the most relevant scenarios are the following:

Impersonation

Once an attacker successfully fixes a session identifier, they can impersonate the victim and gain access to their account without providing valid credentials. This can result in unauthorized actions, such as modifying personal information, making unauthorized transactions, or even performing malicious activities on behalf of the victim. An attacker can also manipulate the victim into performing actions they wouldn’t normally do, such as revealing sensitive information or conducting financial transactions on the attacker’s behalf.

Data Breach

If an attacker gains access to a user’s session, they may also gain access to sensitive data associated with that session. This can include personal information, financial details, or any other confidential data that the user has access to within the application. The compromised data can be used for identity theft, financial fraud, or other malicious purposes.

Privilege Escalation

In some cases, session fixation attacks can be used to escalate privileges within a web application. By fixing a session identifier with higher privileges, an attacker can bypass access controls and gain administrative or privileged access to the application. This can lead to unauthorized modifications, data manipulation, or even complete compromise of the application and its underlying systems.

How to fix it in Symfony

Code examples

In a Symfony Security’s context, session fixation protection can be disabled with the value none for the session_fixation_strategy attribute.

Session fixation protection is enabled by default in Symfony. It can be explicitly enabled with the values migrate and invalidate for the session_fixation_strategy attribute.

Noncompliant code example

namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return static function (ContainerConfigurator $container) {
    $container->extension('security', [
        'session_fixation_strategy' => 'none', // Noncompliant
    ]);
};

Compliant solution

namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return static function (ContainerConfigurator $container) {
    $container->extension('security', [
        'session_fixation_strategy' => 'migrate',
    ]);
};

How does this work?

The protection works by ensuring that the session identifier, which is used to identify and track a user’s session, is changed or regenerated during the authentication process.

Here’s how session fixation protection typically works:

1. When a user visits a website or logs in, a session is created for them. This session is assigned a unique session identifier, which is stored in a cookie or passed through URL parameters.
2. In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. This allows the attacker to potentially gain unauthorized access to the user’s session.
3. To protect against session fixation attacks, session fixation protection mechanisms come into play during the authentication process. When a user successfully authenticates, this mechanism generates a new session identifier for the user’s session.
4. The old session identifier, which may have been manipulated by the attacker, is invalidated and no longer associated with the user’s session. This ensures that any attempts by the attacker to use the fixed session identifier are rendered ineffective.
5. The user is then assigned the new session identifier, which is used for subsequent requests and session tracking. This new session identifier is typically stored in a new session cookie or passed through URL parameters.

By regenerating the session identifier upon authentication, session fixation protection helps ensure that the user’s session is tied to a new, secure identifier that the attacker cannot predict or control. This mitigates the risk of an attacker gaining unauthorized access to the user’s session and helps maintain the integrity and security of the application’s session management process.

Resources

Documentation

Security Configuration Reference - Session Fixation Strategy

Standards

• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A2 - Broken Authentication
• OWASP Sesssion Fixation
• CWE - CWE-384 - Session Fixation

When a cookie is configured with the HttpOnly attribute set to true, the browser guaranties that no client-side script will be able to read it. In most cases, when a cookie is created, the default value of HttpOnly is false and it’s up to the developer to decide whether or not the content of the cookie can be read by the client-side script. As a majority of Cross-Site Scripting (XSS) attacks target the theft of session-cookies, the HttpOnly attribute can help to reduce their impact as it won’t be possible to exploit the XSS vulnerability to steal session-cookies.

Ask Yourself Whether

• the cookie is sensitive, used to authenticate the user, for instance a session-cookie
• the HttpOnly attribute offer an additional protection (not the case for an XSRF-TOKEN cookie / CSRF token for example)

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• By default the HttpOnly flag should be set to true for most of the cookies and it’s mandatory for session / sensitive-security cookies.

Sensitive Code Example

In php.ini you can specify the flags for the session cookie which is security-sensitive:

session.cookie_httponly = 0;  // Sensitive: this sensitive session cookie is created with the httponly flag set to false and so it can be stolen easily in case of XSS vulnerability

Same thing in PHP code:

session_set_cookie_params($lifetime, $path, $domain, true, false);  // Sensitive: this sensitive session cookie is created with the httponly flag (the fifth argument) set to false and so it can be stolen easily in case of XSS vulnerability

If you create a custom security-sensitive cookie in your PHP code:

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true, false); // Sensitive: this sensitive cookie is created with the httponly flag (the seventh argument) set to false  and so it can be stolen easily in case of XSS vulnerability

By default setcookie and setrawcookie functions set httpOnly flag to false (the seventh argument) and so cookies can be stolen easily in case of XSS vulnerability:

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true); // Sensitive: a sensitive cookie is created with the httponly flag  (the seventh argument) not defined (by default set to false)
setrawcookie($name, $value, $expire, $path, $domain, true); // Sensitive: a sensitive cookie is created with the httponly flag (the seventh argument) not defined  (by default set to false)

Compliant Solution

session.cookie_httponly = 1; // Compliant: the sensitive cookie is protected against theft thanks (cookie_httponly=1)

session_set_cookie_params($lifetime, $path, $domain, true, true); // Compliant: the sensitive cookie is protected against theft thanks to the fifth argument set to true (HttpOnly=true)

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true, true); // Compliant: the sensitive cookie is protected against theft thanks to the seventh argument set to true (HttpOnly=true)
setrawcookie($name, $value, $expire, $path, $domain, true, true); // Compliant: the sensitive cookie is protected against theft thanks to the seventh argument set to true (HttpOnly=true)

See

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP HttpOnly
• OWASP - Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• CWE - CWE-1004 - Sensitive Cookie Without 'HttpOnly' Flag
• Derived from FindSecBugs rule HTTPONLY_COOKIE

This rule is deprecated, and will eventually be removed.

Why is this an issue?

Cookies without fixed lifetimes or expiration dates are known as non-persistent, or "session" cookies, meaning they last only as long as the browser session, and poof away when the browser closes. Cookies with expiration dates, "persistent" cookies, are stored/persisted until those dates.

Non-persistent cookies should be used for the management of logged-in sessions on web sites. To make a cookie non-persistent, simply omit the expires attribute.

This rule raises an issue when expires is set for a session cookie, either programmatically or via configuration, such as session.cookie_lifetime.

Resources

• OWASP - Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• OWASP, Session Management Cheat Sheet - Expire and Max-Age Attributes
• Derived from FindSecBugs rule COOKIE_PERSISTENT

When accessing files on the local filesystem, PHP can enforce security checks to defend against some attacks. The open_basedir setting in the main PHP configuration defines a set of directories that the application is allowed to access. Access to locations outside of these directories will be blocked.

Why is this an issue?

The PHP runtime will allow the application to access all files underneath the configured set of directories. If no value is set, the application may access any file on the filesystem.

What is the potential impact?

open_basedir is commonly used to ensure that a PHP application can only access files needed for the application function. While deactivating this setting does not pose a direct threat to the application’s security, it can make exploitation of other vulnerabilities easier and more severe.

If an attacker can exploit a path traversal vulnerability, they will be able to access any file made available to the application’s user account. This may include system-critical or otherwise sensitive files.

In shared hosting environments, a vulnerability can affect all co-hosted applications and not only the vulnerable one. open_basedir can help limit the scope of the compromise in that case.

How to fix it

The main PHP configuration should define the open_basedir setting. This setting should not include overly large directories, such as the root directory of the filesystem.

Adding the current directory, denoted by “.”, to the open_basedir configuration is also dangerous. It is possible to change the current directory within PHP scripts by calling chdir(), effectively removing any protection.

Code examples

Noncompliant code example

; php.ini
open_basedir="/:${USER}/scripts/data"  ; Noncompliant; root directory in the list

; php.ini
; open_basedir= ; Noncompliant; setting commented out

Compliant solution

; php.ini
open_basedir="${USER}/scripts/data"

; php.ini try 1
open_basedir="/var/www/myapp/data"

Resources

Standards

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-23 - Relative Path Traversal
• CWE - CWE-36 - Absolute Path Traversal

This rule is deprecated; use S2631 instead.

Using regular expressions is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-16021
• CVE-2018-13863
• CVE-2018-8926

Evaluating regular expressions against input strings is potentially an extremely CPU-intensive task. Specially crafted regular expressions such as /(a+)+s/ will take several seconds to evaluate the input string aaaaaaaaaaaaaaaaaaaaaaaaaaaaaabs. The problem is that with every additional a character added to the input, the time required to evaluate the regex doubles. However, the equivalent regular expression, a+s (without grouping) is efficiently evaluated in milliseconds and scales linearly with the input size.

Evaluating such regular expressions opens the door to Regular expression Denial of Service (ReDoS) attacks. In the context of a web application, attackers can force the web server to spend all of its resources evaluating regular expressions thereby making the service inaccessible to genuine users.

This rule flags any execution of a hardcoded regular expression which has at least 3 characters and contains at at least two instances of any of the following characters *+{.

Example: (a+)*

The following functions are detected as executing regular expressions:

• PCRE: Perl style regular expressions: preg_filter, preg_grep, preg_match_all, preg_match, preg_replace_callback, preg_replace, preg_split
• POSIX extended, which are deprecated: ereg_replace, ereg, eregi_replace, eregi, split, spliti.
• fnmatch
• Any of the multibyte string regular expressions: mb_eregi_replace, mb_ereg_match, mb_ereg_replace_callback, mb_ereg_replace, mb_ereg_search_init, mb_ereg_search_pos, mb_ereg_search_regs, mb_ereg_search, mb_ereg, mb_eregi_replace, mb_eregi

Note that ereg* functions have been removed in PHP 7 and PHP 5 end of life date is the 1st of January 2019. Using PHP 5 is dangerous as there will be no security fix.

This rule’s goal is to guide security code reviews.

Ask Yourself Whether

• the executed regular expression is sensitive and a user can provide a string which will be analyzed by this regular expression.
• your regular expression engine performance decrease with specially crafted inputs and regular expressions.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Do not set the constant pcre.backtrack_limit to a high value as it will increase the resource consumption of PCRE functions.

Check the error codes of PCRE functions via preg_last_error.

Check whether your regular expression engine (the algorithm executing your regular expression) has any known vulnerabilities. Search for vulnerability reports mentioning the one engine you’re are using. Do not run vulnerable regular expressions on user input.

Use if possible a library which is not vulnerable to Redos Attacks such as Google Re2.

Remember also that a ReDos attack is possible if a user-provided regular expression is executed. This rule won’t detect this kind of injection.

Avoid executing a user input string as a regular expression or use at least preg_quote to escape regular expression characters.

Exceptions

An issue will be created for the functions mb_ereg_search_pos, mb_ereg_search_regs and mb_ereg_search if and only if at least the first argument, i.e. the $pattern, is provided.

The current implementation does not follow variables. It will only detect regular expressions hard-coded directly in the function call.

$pattern = "/(a+)+/";
$result = eregi($pattern, $input);  // No issue will be raised even if it is Sensitive

Some corner-case regular expressions will not raise an issue even though they might be vulnerable. For example: (a|aa)+, (a|a?)+.

It is a good idea to test your regular expression if it has the same pattern on both side of a "|".

See

• OWASP - Top 10 2017 Category A1 - Injection
• CWE - CWE-624 - Executable Regular Expression Error
• OWASP Regular expression Denial of Service - ReDoS

This rule is deprecated, and will eventually be removed.

Using cookies is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2018-11639
• CVE-2016-6537

Attackers can use widely-available tools to read cookies. Any sensitive information they may contain will be exposed.

This rule flags code that writes cookies.

Ask Yourself Whether

• sensitive information is stored inside the cookie.

You are at risk if you answered yes to this question.

Recommended Secure Coding Practices

Cookies should only be used to manage the user session. The best practice is to keep all user-related information server-side and link them to the user session, never sending them to the client. In a very few corner cases, cookies can be used for non-sensitive information that need to live longer than the user session.

Do not try to encode sensitive information in a non human-readable format before writing them in a cookie. The encoding can be reverted and the original information will be exposed.

Using cookies only for session IDs doesn’t make them secure. Follow OWASP best practices when you configure your cookies.

As a side note, every information read from a cookie should be Sanitized.

Sensitive Code Example

$value = "1234 1234 1234 1234";

// Review this cookie as it seems to send sensitive information (credit card number).
setcookie("CreditCardNumber", $value, $expire, $path, $domain, true, true); // Sensitive
setrawcookie("CreditCardNumber", $value, $expire, $path, $domain, true, true); // Sensitive

See

• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• CWE - CWE-312 - Cleartext Storage of Sensitive Information
• CWE - CWE-315 - Cleartext Storage of Sensitive Information in a Cookie
• Derived from FindSecBugs rule COOKIE_USAGE

This rule is deprecated, and will eventually be removed.

A cookie’s domain specifies which websites should be able to read it. Left blank, browsers are supposed to only send the cookie to sites that exactly match the sending domain. For example, if a cookie was set by lovely.dream.com, it should only be readable by that domain, and not by nightmare.com or even strange.dream.com. If you want to allow sub-domain access for a cookie, you can specify it by adding a dot in front of the cookie’s domain, like so: .dream.com. But cookie domains should always use at least two levels.

Cookie domains can be set either programmatically or via configuration. This rule raises an issue when any cookie domain is set with a single level, as in .com.

Ask Yourself Whether

• the domain attribute has only one level as domain naming.

You are at risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• You should check the domain attribute has been set and its value has more than one level of domain nanimg, like: sonarsource.com

Sensitive Code Example

setcookie("TestCookie", $value, time()+3600, "/~path/", ".com", 1); // Noncompliant
session_set_cookie_params(3600, "/~path/", ".com"); // Noncompliant

// inside php.ini
session.cookie_domain=".com"; // Noncompliant

Compliant Solution

setcookie("TestCookie", $value, time()+3600, "/~path/", ".myDomain.com", 1);
session_set_cookie_params(3600, "/~path/", ".myDomain.com");

// inside php.ini
session.cookie_domain=".myDomain.com";

See

• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure

This rule is deprecated, and will eventually be removed.

Why is this an issue?

file_uploads is an on-by-default PHP configuration that allows files to be uploaded to your site. Since accepting candy files from strangers is inherently dangerous, this feature should be disabled unless it is absolutely necessary for your site.

This rule raises an issue when file_uploads is not explicitly disabled.

Noncompliant code example

; php.ini
file_uploads=1  ; Noncompliant

Compliant solution

; php.ini
file_uploads=0

Resources

• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-434 - Unrestricted Upload of File with Dangerous Type

Lightweight Directory Access Protocol (LDAP) servers provide two main authentication methods: the SASL and Simple ones. The Simple Authentication method also breaks down into three different mechanisms:

• Anonymous Authentication
• Unauthenticated Authentication
• Name/Password Authentication

A server that accepts either the Anonymous or Unauthenticated mechanisms will accept connections from clients not providing credentials.

Why is this an issue?

When configured to accept the Anonymous or Unauthenticated authentication mechanism, an LDAP server will accept connections from clients that do not provide a password or other authentication credentials. Such users will be able to read or modify part or all of the data contained in the hosted directory.

What is the potential impact?

An attacker exploiting unauthenticated access to an LDAP server can access the data that is stored in the corresponding directory. The impact varies depending on the permission obtained on the directory and the type of data it stores.

Authentication bypass

If attackers get write access to the directory, they will be able to alter most of the data it stores. This might include sensitive technical data such as user passwords or asset configurations. Such an attack can typically lead to an authentication bypass on applications and systems that use the affected directory as an identity provider.

In such a case, all users configured in the directory might see their identity and privileges taken over.

Sensitive information leak

If attackers get read-only access to the directory, they will be able to read the data it stores. That data might include security-sensitive pieces of information.

Typically, attackers might get access to user account lists that they can use in further intrusion steps. For example, they could use such lists to perform password spraying, or related attacks, on all systems that rely on the affected directory as an identity provider.

If the directory contains some Personally Identifiable Information, an attacker accessing it might represent a violation of regulatory requirements in some countries. For example, this kind of security event would go against the European GDPR law.

How to fix it

Code examples

The following code indicates an anonymous LDAP authentication vulnerability because it binds to a remote server using an Anonymous Simple authentication mechanism.

Noncompliant code example

$ldapconn = ldap_connect("ldap.example.com");

if ($ldapconn) {
    $ldapbind = ldap_bind($ldapconn); // Noncompliant
}

Compliant solution

$ldaprdn  = 'uname';
$ldappass = 'password';

$ldapconn = ldap_connect("ldap.example.com");

if ($ldapconn) {
    $ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass); // Compliant
}

Resources

Documentation

• RFC 4513 - Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms - Bind operations

Standards

• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A2 - Broken Authentication
• CWE - CWE-521 - Weak Password Requirements

Cryptographic hash algorithms such as MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 and SHA-1 are no longer considered secure, because it is possible to have collisions (little computational effort is enough to find two or more different inputs that produce the same hash).

Ask Yourself Whether

The hashed value is used in a security context like:

• User-password storage.
• Security token generation (used to confirm e-mail when registering on a website, reset password, etc …​).
• To compute some message integrity.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Safer alternatives, such as SHA-256, SHA-512, SHA-3 are recommended, and for password hashing, it’s even better to use algorithms that do not compute too "quickly", like bcrypt, scrypt, argon2 or pbkdf2 because it slows down brute force attacks.

Sensitive Code Example

$hash = md5($data); // Sensitive
$hash = sha1($data);   // Sensitive

Compliant Solution

// for a password
$hash = password_hash($password, PASSWORD_BCRYPT); // Compliant

// other context
$hash = hash("sha512", $data);

See

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• OWASP - Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP - Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• CWE - CWE-1240 - Use of a Risky Cryptographic Primitive

This rule is deprecated, and will eventually be removed.

Configuring loggers is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2018-0285
• CVE-2000-1127
• CVE-2017-15113
• CVE-2015-5742

Logs are useful before, during and after a security incident.

• Attackers will most of the time start their nefarious work by probing the system for vulnerabilities. Monitoring this activity and stopping it is the first step to prevent an attack from ever happening.
• In case of a successful attack, logs should contain enough information to understand what damage an attacker may have inflicted.

Logs are also a target for attackers because they might contain sensitive information. Configuring loggers has an impact on the type of information logged and how they are logged.

This rule flags for review code that initiates loggers configuration. The goal is to guide security code reviews.

Ask Yourself Whether

• unauthorized users might have access to the logs, either because they are stored in an insecure location or because the application gives access to them.
• the logs contain sensitive information on a production server. This can happen when the logger is in debug mode.
• the log can grow without limit. This can happen when additional information is written into logs every time a user performs an action and the user can perform the action as many times as he/she wants.
• the logs do not contain enough information to understand the damage an attacker might have inflicted. The loggers mode (info, warn, error) might filter out important information. They might not print contextual information like the precise time of events or the server hostname.
• the logs are only stored locally instead of being backuped or replicated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Check that your production deployment doesn’t have its loggers in "debug" mode as it might write sensitive information in logs.
• Production logs should be stored in a secure location which is only accessible to system administrators.
• Configure the loggers to display all warnings, info and error messages. Write relevant information such as the precise time of events and the hostname.
• Choose log format which is easy to parse and process automatically. It is important to process logs rapidly in case of an attack so that the impact is known and limited.
• Check that the permissions of the log files are correct. If you index the logs in some other service, make sure that the transfer and the service are secure too.
• Add limits to the size of the logs and make sure that no user can fill the disk with logs. This can happen even when the user does not control the logged information. An attacker could just repeat a logged action many times.

Remember that configuring loggers properly doesn’t make them bullet-proof. Here is a list of recommendations explaining on how to use your logs:

• Don’t log any sensitive information. This obviously includes passwords and credit card numbers but also any personal information such as user names, locations, etc…​ Usually any information which is protected by law is good candidate for removal.
• Sanitize all user inputs before writing them in the logs. This includes checking its size, content, encoding, syntax, etc…​ As for any user input, validate using whitelists whenever possible. Enabling users to write what they want in your logs can have many impacts. It could for example use all your storage space or compromise your log indexing service.
• Log enough information to monitor suspicious activities and evaluate the impact an attacker might have on your systems. Register events such as failed logins, successful logins, server side input validation failures, access denials and any important transaction.
• Monitor the logs for any suspicious activity.

Sensitive Code Example

Basic PHP configuration:

function configure_logging() {
  error_reporting(E_RECOVERABLE_ERROR); // Sensitive
  error_reporting(32); // Sensitive

  ini_set('docref_root', '1'); // Sensitive
  ini_set('display_errors', '1'); // Sensitive
  ini_set('display_startup_errors', '1'); // Sensitive
  ini_set('error_log', "path/to/logfile"); // Sensitive - check logfile is secure
  ini_set('error_reporting', E_PARSE ); // Sensitive
  ini_set('error_reporting', 64); // Sensitive
  ini_set('log_errors', '0'); // Sensitive
  ini_set('log_errors_max_length', '512'); // Sensitive
  ini_set('ignore_repeated_errors', '1'); // Sensitive
  ini_set('ignore_repeated_source', '1'); // Sensitive
  ini_set('track_errors', '0'); // Sensitive

  ini_alter('docref_root', '1'); // Sensitive
  ini_alter('display_errors', '1'); // Sensitive
  ini_alter('display_startup_errors', '1'); // Sensitive
  ini_alter('error_log', "path/to/logfile"); // Sensitive - check logfile is secure
  ini_alter('error_reporting', E_PARSE ); // Sensitive
  ini_alter('error_reporting', 64); // Sensitive
  ini_alter('log_errors', '0'); // Sensitive
  ini_alter('log_errors_max_length', '512'); // Sensitive
  ini_alter('ignore_repeated_errors', '1'); // Sensitive
  ini_alter('ignore_repeated_source', '1'); // Sensitive
  ini_alter('track_errors', '0'); // Sensitive
}

Definition of custom loggers with psr/log

abstract class MyLogger implements \Psr\Log\LoggerInterface { // Sensitive
    // ...
}

abstract class MyLogger2 extends \Psr\Log\AbstractLogger { // Sensitive
    // ...
}

abstract class MyLogger3 {
    use \Psr\Log\LoggerTrait; // Sensitive
    // ...
}

Exceptions

No issue will be raised for logger configuration when it follows recommended settings for production servers. The following examples are all valid:

  ini_set('docref_root', '0');
  ini_set('display_errors', '0');
  ini_set('display_startup_errors', '0');

  error_reporting(0);
  ini_set('error_reporting', 0);

  ini_set('log_errors', '1');
  ini_set('log_errors_max_length', '0');
  ini_set('ignore_repeated_errors', '0');
  ini_set('ignore_repeated_source', '0');
  ini_set('track_errors', '1');

See

• OWASP - Top 10 2021 Category A9 - Security Logging and Monitoring Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A10 - Insufficient Logging & Monitoring
• CWE - CWE-117 - Improper Output Neutralization for Logs
• CWE - CWE-532 - Information Exposure Through Log Files

This vulnerability allows attackers to impersonate a trusted host.

Why is this an issue?

Transport Layer Security (TLS) provides secure communication between systems over the internet by encrypting the data sent between them. In this process, the role of hostname validation, combined with certificate validation, is to ensure that a system is indeed the one it claims to be, adding an extra layer of trust and security.

When hostname validation is disabled, the client skips this critical check. This creates an opportunity for attackers to pose as a trusted entity and intercept, manipulate, or steal the data being transmitted.

To do so, an attacker would obtain a valid certificate authenticating example.com, serve it using a different hostname, and the application code would still accept it.

What is the potential impact?

Establishing trust in a secure way is a non-trivial task. When you disable hostname validation, you are removing a key mechanism designed to build this trust in internet communication, opening your system up to a number of potential threats.

Identity spoofing

If a system does not validate hostnames, it cannot confirm the identity of the other party involved in the communication. An attacker can exploit this by creating a fake server and masquerading it as a legitimate one. For example, they might set up a server that looks like your bank’s server, tricking your system into thinking it is communicating with the bank. This scenario, called identity spoofing, allows the attacker to collect any data your system sends to them, potentially leading to significant data breaches.

How to fix it in cURL

Code examples

The following code contains examples of disabled hostname validation.

The hostname validation gets disabled by setting CURLOPT_SSL_VERIFYHOST to 0 or false. To enable validation set the value to 2 or true or do not set CURLOPT_SSL_VERIFYHOST at all to use the secure default value.

Noncompliant code example

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, 'https://example.com/');
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);  // Noncompliant
curl_exec($curl);
curl_close($curl);

Compliant solution

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, 'https://example.com/');
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);
curl_exec($curl);
curl_close($curl);

How does this work?

To fix the vulnerability of disabled hostname validation, it is strongly recommended to first re-enable the default validation and fix the root cause: the validity of the certificate.

Use valid certificates

If a hostname validation failure prevents connecting to the target server, keep in mind that one system’s code should not work around another system’s problems, as this creates unnecessary dependencies and can lead to reliability issues.

Therefore, the first solution is to change the remote host’s certificate to match its identity. If the remote host is not under your control, consider replicating its service to a server whose certificate you can change yourself.

In case the contacted host is located on a development machine, and if there is no other choice, try following this solution:

• Create a self-signed certificate for that machine.
• Add this self-signed certificate to the system’s trust store.
• If the hostname is not localhost, add the hostname in the /etc/hosts file.

Resources

Standards

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• OWASP - Mobile AppSec Verification Standard - Network Communication Requirements
• OWASP - Mobile Top 10 2016 Category M3 - Insecure Communication
• CWE - CWE-297 - Improper Validation of Certificate with Host Mismatch

Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

• CVE-2019-13466
• CVE-2018-15389

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.

This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.

It’s recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", …​

Ask Yourself Whether

• Credentials allow access to a sensitive component like a database, a file storage, an API or a service.
• Credentials are used in production environments.
• Application re-distribution is required before updating the credentials.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Store the credentials in a configuration file that is not pushed to the code repository.
• Store the credentials in a database.
• Use your cloud provider’s service for managing secrets.
• If a password has been disclosed through the source code: change it.

Sensitive Code Example

$password = "65DBGgwe4uazdWQA"; // Sensitive

$httpUrl = "https://example.domain?user=user&password=65DBGgwe4uazdWQA" // Sensitive
$sshUrl = "ssh://user:65DBGgwe4uazdWQA@example.domain" // Sensitive

Compliant Solution

$user = getUser();
$password = getPassword(); // Compliant

$httpUrl = "https://example.domain?user=$user&password=$password" // Compliant
$sshUrl = "ssh://$user:$password@example.domain" // Compliant

See

• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A2 - Broken Authentication
• CWE - CWE-798 - Use of Hard-coded Credentials
• CWE - CWE-259 - Use of Hard-coded Password
• Derived from FindSecBugs rule Hard Coded Password

Clear-text protocols such as ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

• sensitive data exposure
• traffic redirected to a malicious endpoint
• malware-infected software update or installer
• execution of client-side code
• corruption of critical information

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

• bypassing isolation mechanisms
• compromising a component of the network
• getting the credentials of an internal IAM account (either from a service account or an actual person)

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

• CVE-2019-6169
• CVE-2019-12327
• CVE-2019-11065

Ask Yourself Whether

• Application data needs to be protected against falsifications or leaks when transiting over the network.
• Application data transits over an untrusted network.
• Compliance rules require the service to encrypt data in transit.
• Your application renders web pages with a relaxed mixed content policy.
• OS-level protections against clear-text traffic are deactivated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Make application data transit over a secure, authenticated and encrypted protocol like TLS or SSH. Here are a few alternatives to the most common clear-text protocols:
  • Use ssh as an alternative to telnet.
  • Use sftp, scp, or ftps instead of ftp.
  • Use https instead of http.
  • Use SMTP over SSL/TLS or SMTP with STARTTLS instead of clear-text SMTP.
• Enable encryption of cloud components communications whenever it is possible.
• Configure your application to block mixed content when rendering web pages.
• If available, enforce OS-level deactivation of all clear-text traffic.

It is recommended to secure all transport channels, even on local networks, as it can take a single non-secure connection to compromise an entire application or system.

Sensitive Code Example

$url = "http://example.com"; // Sensitive
$url = "ftp://anonymous@example.com"; // Sensitive
$url = "telnet://anonymous@example.com"; // Sensitive

$con = ftp_connect('example.com'); // Sensitive

$trans = (new Swift_SmtpTransport('XXX', 1234)); // Sensitive

$mailer = new PHPMailer(true); // Sensitive

define( 'FORCE_SSL_ADMIN', false); // Sensitive
define( 'FORCE_SSL_LOGIN', false); // Sensitive

Compliant Solution

$url = "https://example.com";
$url = "sftp://anonymous@example.com";
$url = "ssh://anonymous@example.com";

$con = ftp_ssl_connect('example.com');

$trans = (new Swift_SmtpTransport('smtp.example.org', 1234))
  ->setEncryption('tls')
;

$mailer = new PHPMailer(true);
$mailer->SMTPSecure = 'tls';

define( 'FORCE_SSL_ADMIN', true);
define( 'FORCE_SSL_LOGIN', true);

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Insecure protocol scheme followed by loopback addresses like 127.0.0.1 or localhost.

See

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP - Mobile AppSec Verification Standard - Network Communication Requirements
• OWASP - Mobile Top 10 2016 Category M3 - Insecure Communication
• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• CWE - CWE-319 - Cleartext Transmission of Sensitive Information
• Google, Moving towards more secure web
• Mozilla, Deprecating non secure http
• AWS Documentation - Listeners for your Application Load Balancers
• AWS Documentation - Stream Encryption

Rejecting requests with significant content length is a good practice to control the network traffic intensity and thus resource consumption in order to prevent DoS attacks.

Ask Yourself Whether

• size limits are not defined for the different resources of the web application.
• the web application is not protected by rate limiting features.
• the web application infrastructure has limited resources.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• For most of the features of an application, it is recommended to limit the size of requests to:
  • lower or equal to 8mb for file uploads.
  • lower or equal to 2mb for other requests.

It is recommended to customize the rule with the limit values that correspond to the web application.

Sensitive Code Example

For Symfony Constraints:

use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Mapping\ClassMetadata;

class TestEntity
{
    public static function loadValidatorMetadata(ClassMetadata $metadata)
    {
        $metadata->addPropertyConstraint('upload', new Assert\File([
            'maxSize' => '100M', // Sensitive
        ]));
    }
}

For Laravel Validator:

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class TestController extends Controller
{
    public function test(Request $request)
    {
        $validatedData = $request->validate([
            'upload' => 'required|file', // Sensitive
        ]);
    }
}

Compliant Solution

For Symfony Constraints:

use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Mapping\ClassMetadata;

class TestEntity
{
    public static function loadValidatorMetadata(ClassMetadata $metadata)
    {
        $metadata->addPropertyConstraint('upload', new Assert\File([
            'maxSize' => '8M', // Compliant
        ]));
    }
}

For Laravel Validator:

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class TestController extends Controller
{
    public function test(Request $request)
    {
        $validatedData = $request->validate([
            'upload' => 'required|file|max:8000', // Compliant
        ]);
    }
}

See

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• Owasp Cheat Sheet - Owasp Denial of Service Cheat Sheet
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-770 - Allocation of Resources Without Limits or Throttling
• CWE - CWE-400 - Uncontrolled Resource Consumption

Secret leaks often occur when a sensitive piece of authentication data is stored with the source code of an application. Considering the source code is intended to be deployed across multiple assets, including source code repositories or application hosting servers, the secrets might get exposed to an unintended audience.

Why is this an issue?

In most cases, trust boundaries are violated when a secret is exposed in a source code repository or an uncontrolled deployment environment. Unintended people who don’t need to know the secret might get access to it. They might then be able to use it to gain unwanted access to associated services or resources.

The trust issue can be more or less severe depending on the people’s role and entitlement.

What is the potential impact?

The consequences vary greatly depending on the situation and the secret-exposed audience. Still, two main scenarios should be considered.

Financial loss

Financial losses can occur when a secret is used to access a paid third-party-provided service and is disclosed as part of the source code of client applications. Having the secret, each user of the application will be able to use it without limit to use the third party service to their own need, including in a way that was not expected.

This additional use of the secret will lead to added costs with the service provider.

Moreover, when rate or volume limiting is set up on the provider side, this additional use can prevent the regular operation of the affected application. This might result in a partial denial of service for all the application’s users.

Application’s security downgrade

A downgrade can happen when the disclosed secret is used to protect security-sensitive assets or features of the application. Depending on the affected asset or feature, the practical impact can range from a sensitive information leak to a complete takeover of the application, its hosting server or another linked component.

For example, an application that would disclose a secret used to sign user authentication tokens would be at risk of user identity impersonation. An attacker accessing the leaked secret could sign session tokens for arbitrary users and take over their privileges and entitlements.

How to fix it

Revoke the secret

Revoke any leaked secrets and remove them from the application source code.

Before revoking the secret, ensure that no other applications or processes are using it. Other usages of the secret will also be impacted when the secret is revoked.

Analyze recent secret use

When available, analyze authentication logs to identify any unintended or malicious use of the secret since its disclosure date. Doing this will allow determining if an attacker took advantage of the leaked secret and to what extent.

This operation should be part of a global incident response process.

Use a secret vault

A secret vault should be used to generate and store the new secret. This will ensure the secret’s security and prevent any further unexpected disclosure.

Depending on the development platform and the leaked secret type, multiple solutions are currently available.

Code examples

The following code example is noncompliant because it uses a hardcoded secret value.

Noncompliant code example

use Defuse\Crypto\KeyOrPassword;

function createKey() {
    $password = "3xAmpl3";  // Noncompliant
    return KeyOrPassword::createFromPassword($password);
}

Compliant solution

use Defuse\Crypto\KeyOrPassword;

function createKey() {
    $password = $_ENV["SECRET"]
    return KeyOrPassword::createFromPassword($password);
}

How does this work?

While the noncompliant code example contains a hard-coded password, the compliant solution retrieves the secret’s value from its environment. This allows to have an environment-dependent secret value and avoids storing the password in the source code itself.

Depending on the application and its underlying infrastructure, how the secret gets added to the environment might change.

Resources

Documentation

• AWS Documentation - What is AWS Secrets Manager
• Azure Documentation - Azure Key Vault
• Google Cloud - Secret Manager documentation
• HashiCorp Developer - Vault Documentation
• Symfony - How to Keep Sensitive Information Secret

Standards

• OWASP - Top 10 2021 - Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 - Category A2 - Broken Authentication
• CWE - CWE-798 - Use of Hard-coded Credentials
• CWE - CWE-259 - Use of Hard-coded Password

This rule is deprecated; use S4790 instead.

Why is this an issue?

The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2, MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.

Consider using safer alternatives, such as SHA-256, SHA-512 or SHA-3.

Noncompliant code example

$password = ...

if (md5($password) === '1f3870be274f6c49b3e31a0c6728957f') { // Noncompliant; md5() hashing algorithm is not secure for password management
   [...]
}

if (sha1($password) === 'd0be2dc421be4fcd0172e5afceea3970e2f3d940') { // Noncompliant; sha1() hashing algorithm is not secure for password management
   [...]
}

Resources

• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• CWE - CWE-328 - Reversible One-Way Hash
• CWE - CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SHAttered - The first concrete collision attack against SHA-1.

Formatted SQL queries can be difficult to maintain, debug and can increase the risk of SQL injection when concatenating untrusted values into the query. However, this rule doesn’t detect SQL injections (unlike rule S3649), the goal is only to highlight complex/formatted queries.

Ask Yourself Whether

• Some parts of the query come from untrusted values (like user inputs).
• The query is repeated/duplicated in other parts of the code.
• The application must support different types of relational databases.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use parameterized queries, prepared statements, or stored procedures and bind variables to SQL query parameters.
• Consider using ORM frameworks if there is a need to have an abstract layer to access data.

Sensitive Code Example

$id = $_GET['id'];
mysql_connect('localhost', $username, $password) or die('Could not connect: ' . mysql_error());
mysql_select_db('myDatabase') or die('Could not select database');

$result = mysql_query("SELECT * FROM myTable WHERE id = " . $id);  // Sensitive, could be susceptible to SQL injection

while ($row = mysql_fetch_object($result)) {
    echo $row->name;
}

Compliant Solution

$id = $_GET['id'];
try {
    $conn = new PDO('mysql:host=localhost;dbname=myDatabase', $username, $password);
    $conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

    $stmt = $conn->prepare('SELECT * FROM myTable WHERE id = :id');
    $stmt->execute(array('id' => $id));

    while($row = $stmt->fetch(PDO::FETCH_OBJ)) {
        echo $row->name;
    }
} catch(PDOException $e) {
    echo 'ERROR: ' . $e->getMessage();
}

Exceptions

No issue will be raised if one of the functions is called with hard-coded string (no concatenation) and this string does not contain a "$" sign.

$result = mysql_query("SELECT * FROM myTable WHERE id = 42") or die('Query failed: ' . mysql_error());  // Compliant

The current implementation does not follow variables. It will only detect SQL queries which are concatenated or contain a $ sign directly in the function call.

$query = "SELECT * FROM myTable WHERE id = " . $id;
$result = mysql_query($query);  // No issue will be raised even if it is Sensitive

See

• OWASP - Top 10 2021 Category A3 - Injection
• OWASP - Top 10 2017 Category A1 - Injection
• CWE - CWE-20 - Improper Input Validation
• CWE - CWE-89 - Improper Neutralization of Special Elements used in an SQL Command
• Derived from FindSecBugs rules Potential SQL/JPQL Injection (JPA), Potential SQL/JDOQL Injection (JDO), Potential SQL/HQL Injection (Hibernate)

This vulnerability allows the usage of external entities in XML.

Why is this an issue?

External Entity Processing allows for XML parsing with the involvement of external entities. However, when this functionality is enabled without proper precautions, it can lead to a vulnerability known as XML External Entity (XXE) attack.

What is the potential impact?

Exposing sensitive data

One significant danger of XXE vulnerabilities is the potential for sensitive data exposure. By crafting malicious XML payloads, attackers can reference external entities that contain sensitive information, such as system files, database credentials, or configuration files. When these entities are processed during XML parsing, the attacker can extract the contents and gain unauthorized access to sensitive data. This poses a severe threat to the confidentiality of critical information.

Exhausting system resources

Another consequence of XXE vulnerabilities is the potential for denial-of-service attacks. By exploiting the ability to include external entities, attackers can construct XML payloads that cause resource exhaustion. This can overwhelm the system’s memory, CPU, or other critical resources, leading to system unresponsiveness or crashes. A successful DoS attack can disrupt the availability of services and negatively impact the user experience.

Forging requests

XXE vulnerabilities can also enable Server-Side Request Forgery (SSRF) attacks. By leveraging the ability to include external entities, an attacker can make the vulnerable application send arbitrary requests to other internal or external systems. This can result in unintended actions, such as retrieving data from internal resources, scanning internal networks, or attacking other systems. SSRF attacks can lead to severe consequences, including unauthorized data access, system compromise, or even further exploitation within the network infrastructure.

How to fix it in Core PHP

Code examples

The following code contains examples of XML parsers that have external entity processing enabled. As a result, the parsers are vulnerable to XXE attacks if an attacker can control the XML file that is processed.

Noncompliant code example

$xml = file_get_contents('xxe.xml');
$doc = simplexml_load_string($xml, 'SimpleXMLElement', LIBXML_NOENT); // Noncompliant

$doc = new DOMDocument();
$doc->load('xxe.xml', LIBXML_NOENT); // Noncompliant

$reader = new XMLReader();
$reader->open('xxe.xml');
$reader->setParserProperty(XMLReader::SUBST_ENTITIES, true); // Noncompliant

Compliant solution

External entity substitution is disabled by default in simplexml_load_string() and DOMDocument::open().

$xml = file_get_contents('xxe.xml');
$doc = simplexml_load_string($xml, 'SimpleXMLElement');

$doc = new DOMDocument();
$doc->load('xxe.xml');

$reader = new XMLReader();
$reader->open('xxe.xml');
$reader->setParserProperty(XMLReader::SUBST_ENTITIES, false);

How does this work?

Disable external entities

The most effective approach to prevent XXE vulnerabilities is to disable external entity processing entirely, unless it is explicitly required for specific use cases. By default, XML parsers should be configured to reject the processing of external entities. This can be achieved by setting the appropriate properties or options in your XML parser library or framework.

If external entity processing is necessary for certain scenarios, adopt a whitelisting approach to restrict the entities that can be resolved during XML parsing. Create a list of trusted external entities and disallow all others. This approach ensures that only known and safe entities are processed.
You should rely on features provided by your XML parser to restrict the external entities.

Resources

Standards

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2017 Category A4 - XML External Entities (XXE)
• CWE - CWE-611 - Information Exposure Through XML External Entity Reference
• CWE - CWE-827 - Improper Control of Document Type Definition

This rule is deprecated, and will eventually be removed.

Using sockets is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2011-178
• CVE-2017-5645
• CVE-2018-6597

Sockets are vulnerable in multiple ways:

• They enable a software to interact with the outside world. As this world is full of attackers it is necessary to check that they cannot receive sensitive information or inject dangerous input.
• The number of sockets is limited and can be exhausted. Which makes the application unresponsive to users who need additional sockets.

This rules flags code that creates sockets. It matches only the direct use of sockets, not use through frameworks or high-level APIs such as the use of http connections.

Ask Yourself Whether

• sockets are created without any limit every time a user performs an action.
• input received from sockets is used without being sanitized.
• sensitive data is sent via sockets without being encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• In many cases there is no need to open a socket yourself. Use instead libraries and existing protocols.
• Encrypt all data sent if it is sensitive. Usually it is better to encrypt it even if the data is not sensitive as it might change later.
• Sanitize any input read from the socket.
• Limit the number of sockets a given user can create. Close the sockets as soon as possible.

Sensitive Code Example

function handle_sockets($domain, $type, $protocol, $port, $backlog, $addr, $hostname, $local_socket, $remote_socket, $fd) {
    socket_create($domain, $type, $protocol); // Sensitive
    socket_create_listen($port, $backlog); // Sensitive
    socket_addrinfo_bind($addr); // Sensitive
    socket_addrinfo_connect($addr); // Sensitive
    socket_create_pair($domain, $type, $protocol, $fd);

    fsockopen($hostname); // Sensitive
    pfsockopen($hostname); // Sensitive
    stream_socket_server($local_socket); // Sensitive
    stream_socket_client($remote_socket); // Sensitive
    stream_socket_pair($domain, $type, $protocol); // Sensitive
}

See

• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• CWE - CWE-20 - Improper Input Validation
• CWE - CWE-400 - Uncontrolled Resource Consumption ('Resource Exhaustion')
• CWE - CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor

This rule is deprecated, and will eventually be removed.

Why is this an issue?

sleep is sometimes used in a mistaken attempt to prevent Denial of Service (DoS) attacks by throttling response rate. But because it ties up a thread, each request takes longer to serve that it otherwise would, making the application more vulnerable to DoS attacks, rather than less.

Noncompliant code example

if (is_bad_ip($requester)) {
  sleep(5);  // Noncompliant
}

Resources

• OWASP - Top 10 2017 Category A6 - Security Misconfiguration

If a session ID can be guessed (not generated with a secure pseudo random generator, or with insufficient length …​) an attacker may be able to hijack another user’s session.

Ask Yourself Whether

• the session ID is not unique.
• the session ID is set from a user-controlled input.
• the session ID is generated with not secure pseudo random generator.
• the session ID length is too short.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Don’t manually generate session IDs, use instead language based native functionality.

Sensitive Code Example

session_id(bin2hex(random_bytes(4))); // Sensitive: 4 bytes is too short
session_id($_POST["session_id"]); // Sensitive: session ID can be specified by the user

Compliant Solution

session_regenerate_id(); ; // Compliant
session_id(bin2hex(random_bytes(16))); // Compliant

See

• OWASP - Top 10 2021 Category A4 - Insecure Design
• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Sesssion Fixation
• CWE - CWE-330 - Use of Insufficiently Random Values
• CWE - CWE-340 - Generation of Predictable Numbers or Identifiers
• PHP: random_bytes()
• PHP: session_regenerate_id()

Executing code dynamically is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-9807
• CVE-2017-9802

Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific meta-programming use-cases. However most of the time their use is frowned upon as they also increase the risk of Injected Code. Such attacks can either run on the server or in the client (exemple: XSS attack) and have a huge impact on an application’s security.

This rule marks for review each occurrence of the eval function. This rule does not detect code injections. It only highlights the use of APIs which should be used sparingly and very carefully. The goal is to guide security code reviews.

Ask Yourself Whether

• the executed code may come from an untrusted source and hasn’t been sanitized.
• you really need to run code dynamically.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Regarding the execution of unknown code, the best solution is to not run code provided by an untrusted source. If you really need to do it, run the code in a sandboxed environment. Use jails, firewalls and whatever means your operating system and programming language provide (example: Security Managers in java, iframes and same-origin policy for javascript in a web browser).

Do not try to create a blacklist of dangerous code. It is impossible to cover all attacks that way.

Avoid using dynamic code APIs whenever possible. Hard-coded code is always safer.

Sensitive Code Example

eval($code_to_be_dynamically_executed)

See

• OWASP - Top 10 2021 Category A3 - Injection
• OWASP - Top 10 2017 Category A1 - Injection
• CWE - CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

This vulnerability increases the likelihood that attackers are able to compute the cleartext of password hashes.

Why is this an issue?

During the process of password hashing, an additional component, known as a "salt," is often integrated to bolster the overall security. This salt, acting as a defensive measure, primarily wards off certain types of attacks that leverage pre-computed tables to crack passwords.

However, potential risks emerge when the salt is deemed insecure. This can occur when the salt is consistently the same across all users or when it is too short or predictable. In scenarios where users share the same password and salt, their password hashes will inevitably mirror each other. Similarly, a short salt heightens the probability of multiple users unintentionally having identical salts, which can potentially lead to identical password hashes. These identical hashes streamline the process for potential attackers to recover clear-text passwords. Thus, the emphasis on implementing secure, unique, and sufficiently lengthy salts in password-hashing functions is vital.

What is the potential impact?

Despite best efforts, even well-guarded systems might have vulnerabilities that could allow an attacker to gain access to the hashed passwords. This could be due to software vulnerabilities, insider threats, or even successful phishing attempts that give attackers the access they need.

Once the attacker has these hashes, they will likely attempt to crack them using a couple of methods. One is brute force, which entails trying every possible combination until the correct password is found. While this can be time-consuming, having the same salt for all users or a short salt can make the task significantly easier and faster.

If multiple users have the same password and the same salt, their password hashes would be identical. This means that if an attacker successfully cracks one hash, they have effectively cracked all identical ones, granting them access to multiple accounts at once.

A short salt, while less critical than a shared one, still increases the odds of different users having the same salt. This might create clusters of password hashes with identical salt that can then be attacked as explained before.

With short salts, the probability of a collision between two users' passwords and salts couple might be low depending on the salt size. The shorter the salt, the higher the collision probability. In any case, using longer, cryptographically secure salt should be preferred.

Exceptions

To securely store password hashes, it is a recommended to rely on key derivation functions that are computationally intensive. Examples of such functions are:

• Argon2
• PBKDF2
• Scrypt
• Bcrypt

When they are used for password storage, using a secure, random salt is required.

However, those functions can also be used for other purposes such as master key derivation or password-based pre-shared key generation. In those cases, the implemented cryptographic protocol might require using a fixed salt to derive keys in a deterministic way. In such cases, using a fixed salt is safe and accepted.

How to fix it in Core PHP

Code examples

The following code contains examples of hard-coded salts.

Noncompliant code example

$salt = 'salty';
$hash = hash_pbkdf2('sha256', $password, $salt, 100000); // Noncompliant

Compliant solution

$salt = random_bytes(16);
$hash = hash_pbkdf2('sha256', $password, $salt, 100000);

How does this work?

This code ensures that each user’s password has a unique salt value associated with it. It generates a salt randomly and with a length that provides the required security level. It uses a salt length of at least 32 bytes (256 bits), as recommended by industry standards.

Here, the compliant code example ensures the salt is random and has a sufficient length by calling the random_bytes function with a length parameter set to 16. This one internally uses a cryptographically secure pseudo random number generator.

Resources

Standards

• OWASP - Top 10 2021 Category A2 - Cryptographic Failures
• OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
• CWE - CWE-759 - Use of a One-Way Hash without a Salt
• CWE - CWE-760 - Use of a One-Way Hash with a Predictable Salt

In Unix file system permissions, the "others" category refers to all users except the owner of the file system resource and the members of the group assigned to this resource.

Granting permissions to this category can lead to unintended access to files or directories that could allow attackers to obtain sensitive information, disrupt services or elevate privileges.

Ask Yourself Whether

• The application is designed to be run on a multi-user environment.
• Corresponding files and directories may contain confidential information.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

The most restrictive possible permissions should be assigned to files and directories.

Sensitive Code Example

chmod("foo", 0777); // Sensitive

umask(0); // Sensitive
umask(0750); // Sensitive

For Symfony Filesystem:

use Symfony\Component\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0777); // Sensitive

For Laravel Filesystem:

use Illuminate\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0777); // Sensitive

Compliant Solution

chmod("foo", 0750); // Compliant

umask(0027); // Compliant

For Symfony Filesystem:

use Symfony\Component\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0750); // Compliant

For Laravel Filesystem:

use Illuminate\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0750); // Compliant

See

• OWASP - Top 10 2021 Category A1 - Broken Access Control
• OWASP - Top 10 2021 Category A4 - Insecure Design
• OWASP - Top 10 2017 Category A5 - Broken Access Control
• OWASP File Permission
• CWE - CWE-732 - Incorrect Permission Assignment for Critical Resource
• CWE - CWE-266 - Incorrect Privilege Assignment

External requests initiated by a WordPress server should be considered as security-sensitive. They may contain sensitive data which is stored in the files or in the database of the server. It’s important for the administrator of a WordPress server to understand what they contain and to which server they are sent.

WordPress makes it possible to block external requests by setting the WP_HTTP_BLOCK_EXTERNAL option to true. It’s then possible to authorize requests to only a few servers using another option named WP_ACCESSIBLE_HOSTS.

Ask Yourself Whether

• Your WordPress website contains code which may call external requests to servers you don’t know.
• Your WordPress website may send sensitive data to other servers.
• Your WordPress website uses a lot of plugins or themes.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Uninstall WordPress plugins which send requests to servers you don’t know.
• Make sure that WP_HTTP_BLOCK_EXTERNAL is defined in wp-config.php.
• Make sure that WP_HTTP_BLOCK_EXTERNAL is set to true.
• Make sure that WP_ACCESSIBLE_HOSTS is configured to authorize requests to the servers you trust.

Sensitive Code Example

define( 'WP_HTTP_BLOCK_EXTERNAL', false ); // Sensitive

Compliant Solution

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org' );

See

• OWASP - Top 10 2021 Category A5 - Security Misconfiguration
• OWASP - Top 10 2021 Category A10 - Server-Side Request Forgery (SSRF)
• wordpress.org - Block External URL Requests
• OWASP - Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Attack Category - Server Side Request Forgery
• CWE - CWE-918 - Server-Side Request Forgery (SSRF)