The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions that result in periodic version updates. Each new revision addresses security weaknesses discovered in the previous version. Use of an insecure version of TLS/SSL weakens the strength of the data protection and might allow an attacker to compromise, steal, or modify sensitive information.

Insecure versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing

The presence of these properties might enable an attacker to intercept, modify, or tamper with sensitive data.

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Unencrypted communication channels are prone to eavesdropping and tampering.

By default, in apiVersion 2019-04-01 and later, Azure storage accounts require a secure connection to respond to requests, but the requirement can be disabled with the supportsHttpsTrafficOnly property.

Disabling transfer security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example template shows a storage account that does not enforce secure transfer.

{
    "name": "Storage1",
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2021-02-01",
    ...
    "properties": {
        "supportsHttpsTrafficOnly": false
    }
}

By default, Azure Kubernetes Service (AKS) clusters do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example template shows an AKS cluster that does not send log events to Azure Monitor.

{
    "name": "[split(parameters('aksResourceId'),'/')[8]]",
    "type": "Microsoft.ContainerService/managedClusters",
    "apiVersion": "2018-03-31",
    "properties": {
        "mode": "Incremental",
        "id": "[parameters('aksResourceId')]",
    }
}

A short retention period reduces the amount of log information that the organization can consult in the event of an investigation. Industry standards recommend different retention periods depending on the type of data and the legal obligations required for the organization.

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Example 1: The following example template defines an Azure Monitor log profile that does not collect all Activity Log administrative events.

{
    "name": "string",
    "type": "microsoft.insights/logprofiles",
    "apiVersion": "2016-03-01",
    ...
    "properties": {
        ...
        "categories": [
            "Write"
        ],
        ...
    }
}

Unmonitored systems provide attackers with a way to probe and potentially penetrate defenses without detection.

If security personnel are not alerted in a timely fashion to security-related events, they cannot respond to incidents in time to reduce the impact of an attack or breach.

Example 1: The following example template successfully defines a security contact but explicitly disables the delivery of security alert email notifications to that contact.

{
    "name": "Security Officer",
    "type": "Microsoft.Security/securityContacts",
    "apiVersion": "2020-01-01-preview",
    "properties": {
        "emails": "secofficer@example.com",
        "phone": "1212131314",
        "alertNotifications": {
        "state": "Off",
        "minimalSeverity": "High"
        },
        ...
}

A short retention period reduces the amount of log information that the organization can consult in the event of an investigation. Industry standards recommend different retention periods depending on the type of data and the legal obligations required for the organization.

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Example 1: The following example template shows an Azure SQL server configuration without auditing enabled.

{
    "name": "ProdSQLServer",
    "type": "Microsoft.Sql/servers",
    "apiVersion": "2021-02-01-preview",
    ...
    "properties": {
        "collation": "SQL_Latin1_General_CP1_CI_AS",
        ...
        "resources": []
    }
    ...
}

Touch ID based authentication can be implemented in two different flavors: using the LocalAuthentication framework or using Touch ID based access controls in the Keychain service.

Although both of them should be strong enough for most applications, the LocalAuthentication approach has some characteristics that make it less suitable for high risk apps such as banking, medical, and insurance:

- LocalAuthentication is defined outside of the device's Secure Enclave which implies that their APIs can be hooked and modified on jailbroken devices.
- LocalAuthentication authenticates the user by evaluating the context policy which may only evaluate to true or false. This boolean evaluation implies that the application will not be able to know who is really being authenticated, it just knows that fingerprint that is registered with the device was used or not. In addition, fingerprints that could be registered in the future will also successfully evaluate to true.


Example 1: The following code uses the LocalAuthentication framework to perform user authentication:

    ...
    let context:LAContext = LAContext();  
    var error:NSError?  
    let reason:String = "Please authenticate using the Touch ID sensor."
    
    if (context.canEvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, error: &error))  {
        context.evaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, localizedReason: reason, reply: { (success, error) -> Void in
            if (success) {
                // Fingerprint was authenticated
            }
            else {
                // Fingerprint could not be authenticated
            }
        })
    }
    ...

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, and the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.

Example 1: In the following example, a cookie is created without setting the isSecure parameter to true.

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

If your application uses both HTTPS and HTTP but does not set the isSecure parameter, cookies sent during an HTTPS request are also sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, and sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.

Example 1: In the following example, a cookie is added to the response without setting the Secure property.

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or session identifiers, or carries a CSRF token.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure property to true.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure flag.

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or session identifiers, or carries a CSRF token.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure flag.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure flag.

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the HttpOnly property.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

Browsers support the HttpOnly cookie property that prevents client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without HttpOnly enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the HttpOnly property.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the httpOnly property.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the HttpOnly property.

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

Browsers support the HttpOnly cookie property that prevents client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without HttpOnly enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the HttpOnly property.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the HttpOnly property.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a session cookie without setting the HttpOnly flag to true.

session_set_cookie_params(0, "/", "www.example.com", true, false);

Browsers support the HttpOnly cookie property that prevents client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without HttpOnly enabled, attackers have easier access to user cookies.

Example 1: The following settings configuration explicitly sets the session cookies without setting the HttpOnly property.

...
MIDDLEWARE = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...
SESSION_COOKIE_HTTPONLY = False
...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code sets the SameSite attribute to None for session cookies.

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appends the cookie to the request.

The SameSite attribute limits the scope of the cookie such that it will only be attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originating from third-party sites, including those that have either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.

Example 1: The following code disables the SameSite attribute for session cookies.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.None;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appends the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originating from third-party sites, including those that have either iframe or href tags that link to the host site. For example, suppose there is a third-party site that has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute limits the scope of the cookie such that it will only be attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.

Example 1: The following code disables the SameSite attribute for session cookies.

ini_set("session.cookie_samesite", "None");

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The samesite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The samesite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

  response.set_cookie("cookie", value="samesite-none", samesite=None)

The SameSite attribute protects cookies from Cross-Site Request Forgery (CSRF) attacks. The browser automatically appends cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data like session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.
The SameSite attribute on a cookie allows sites to control that behaviour and prevents browsers from appending the cookie to request if the request is generated from a third-party site page load. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top level navigation.
- Lax: When set to Lax, cookies are sent with top level navigation from the same host as well as GET requests originated to the host from third-party sites (for example, in iframe, link, href, and so on and the form tag with GET method only).
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.
Cookies that have the SameSite attribute with the value of None must be set with the Secure attribute otherwise the browser rejects the cookies. Additionally, a few specific browser versions reject the SameSite cookie with the None value for example, Chrome versions 51 to 66, versions of the UC Browser on Android prior to version 12.13.2, versions of Safari and embedded browsers on macOS 10.14, and all browsers on iOS 12 reject cookies set with SameSite=None. A suggested workaround for this issue is to set an alternate cookie with a prefix or suffix such as Legacy appended to cookiename. Sites can look for this legacy cookie if it does not find a cookie that was set with SameSite=None.