WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and secures the message itself.

. The absence of an OutflowSecurity parameter in the Apache Axis 2 configuration file indicates that outbound message security is not enabled.

WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security eliminates the transport security dependency and builds security into the message itself.

The absence of an InflowSecurity parameter in the Apache Axis 2 configuration file indicates that inbound message security is not enabled.

WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security eliminates the transport security dependency and builds security into the message itself.

The absence of an OutflowSecurity parameter in the Apache Axis 2 configuration file indicates that outbound message security is not enabled.

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and secures the message itself.

The absence of an InflowSecurity parameter in the Apache Axis 2 configuration file indicates that inbound message security is not enabled.

Overly broad configurations expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g. Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template allows unrestricted inbound traffic to a range of ports, including the RDP service port (3389).

resource example 'Microsoft.Network/networkSecurityGroups/securityRules@2020-11-01' = {
    ...
    properties: {
        ...
        description: 'Services Inbound Range'
        protocol: 'Tcp'
        sourcePortRange: '*'
        destinationPortRanges: [ '3333-3389' ]
        sourceAddressPrefix: '*'
        destinationAddressPrefix: '*'
        access: 'Allow'
        priority: 100
        direction: 'Inbound'
    }
}

Overly broad configurations expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g. Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example Ansible task allows unrestricted inbound traffic to a range of ports, including the RDP service port (3389).

- name: testFWRule
    azure_rm_securitygroup:
        resource_group: testRG
        name: test
        rules:
        - name: rule001
            priority: 100
            direction: Inbound
            access: Allow
            protocol: "*"
            source_port_range: "*"
            destination_port_range: "3388-3398"
            source_address_prefix: "*"
            destination_address_prefix: "*"
        - name: rule002
            priority: 100
            direction: Inbound
            access: Allow
            protocol: "*"
            source_port_range: "*"
            destination_port_range: 22
            source_address_prefix: "*"
            destination_address_prefix: "*"

Content Security Policy (CSP) is an HTTP response security header that developers can leverage to specify external domains from which the site is allowed to load resources such as images and JavaScript files. This header provides in-depth security protection from critical vulnerabilities such as cross-site scripting (XSS) and clickjacking. Before Content-Security-Policy was standardized under the current header, two different experimental equivalents of this header existed: X-Content-Security-Policy and X-WebKit-CSP. The X-Content-Security-Policy was implemented and maintained in Firefox until version 23 and in Internet Explorer until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Some browsers might still accept the header, but modern browsers no longer maintain, support, or enhance implementation of these two experimental versions.

Content Security Policy (CSP) is a declarative security header that enables developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code.

The Content-Security-Policy-Report-Only header provides the capability for web application authors and administrators to monitor security policies, rather than enforce them. This header is typically used when experimenting and/or developing security policies for a site. When a policy is deemed effective, you can be enforce it by using the Content-Security-Policy header field instead.

Example 1: The following code sets a Content Security Policy in Report-Only mode:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

A single <security constraint> element suggests the program does not employ role-based access control, which is commonly accepted best practice for protecting sensitive operations in secure web applications. If the application provides access to sensitive operations or data, there might not be sufficient controls in place to prevent unauthorized users from gaining access. Furthermore, if there is a wildcard (*) in the <url-pattern>, it can be an indication that the pattern is overly broad.

App Transport Security (ATS) enforces best practices for secure network connections such as TLS 1.2 and forward secrecy and will be updated in the future to reflect Apple's network best practices.

App Transport Security (ATS) is enabled by default when using NSURLSession, NSURLConnection, or CFURL in iOS 9 or OS X El Capitan which enforces the application to use HTTPS with TLS 1.2 for all the network communications with the back end server.

The application is configured to partially or entirely opt-out of App Transport Security (ATS) which leaves the application at risk of suffering man-in-the-middle attacks and other network-based attacks.

Example 1: The following entries in the application Info.plist will entirely disable App Transport Security:

<key>NSAppTransportSecurity</key>
<dict>
  <!--Include to allow all connections (DANGER)-->
  <key>NSAllowsArbitraryLoads</key>
  <true/>
</dict>

Example 2: The following entries in the application Info.plist will disable App Transport Security for yourserver.com:

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>yourserver.com</key>
    <dict>
      <!--Include to allow subdomains-->
      <key>NSIncludesSubdomains</key>
      <true/>
      <!--Allow plain HTTP requests-->
      <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
      <true/>
      <!--Downgrades TLS version-->
      <key>NSTemporaryExceptionMinimumTLSVersion</key>
      <string>TLSv1.1</string>
    </dict>
  </dict>
</dict>

The Network Security Configuration feature lets apps customize their network security settings in a safe, declarative configuration file without modifying app code. These settings can be configured for specific domains and for a specific app. The key capabilities of this feature are as follows:
- Custom trust anchors: Customize which Certificate Authorities (CA) are trusted for an app's secure connections. For example, trusting particular self-signed certificates or restricting the set of public CAs that the app trusts.
- Debug-only overrides: Safely debug secure connections in an app without added risk to the installed base.
- Cleartext traffic opt-out: Protect apps from accidental usage of cleartext traffic.
- Certificate pinning: Restrict an app's secure connection to particular certificates.

Content Security Policy (CSP) is a declarative security header that enables developers to specify allowed security-related behavior within the browser, including an allow list of locations from which content can be retrieved. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of 15 directives including 8 that control resource access: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. These 8 directives take a source list as a value that specifies domains the site is allowed to access for a feature covered by that directive. Developers can use a wildcard * to indicate all or part of the source. Additional source list keywords such as 'unsafe-inline' and 'unsafe-eval' provide more granular control over script execution but are potentially harmful. None of the directives are mandatory. Browsers either allow all sources for an unlisted directive or derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of these names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer can misconfigure this header.

Example 1: The following code sets an overly permissive and insecure default-src directive:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

The XML Signature secure validation mode enables the validation of XML digital signatures and restricts several XML constructs to avoid some Denial of Service and other types of attacks.

Such restrictions include:
- Forbids the use of XSLT transforms.
- Restricts the number of SignedInfo or Manifest Reference elements to 30 or less.
- Restricts the number of Reference transforms to 5 or less.
- Forbids the use of MD5 signatures or MD5 MAC algorithms.
- Ensures that Reference IDs are unique to help prevent signature wrapping attacks.
- Forbids Reference URIs of type http, https, or file.
- Does not allow a RetrievalMethod element to reference another RetrievalMethod element.
- Forbids RSA or DSA keys less than 1024 bits.
- Forbids EC keys less than 224 bits.

Example 1: The following code disables XML Signature secure validation with a system property:

Properties props = System.getProperties();
...
properties.setProperty("org.jcp.xml.dsig.secureValidation", "false");

Example 2: The following code disables XML Signature secure validation with XMLCryptoContext.setProperty:

DOMCryptoContext cryptoContext = new DOMCryptoContext() {...};
...
cryptoContext.setProperty("org.jcp.xml.dsig.secureValidation", false);

Any area of the website, or web application, that contains sensitive information or access to privileged functionality such as remote site administration requires that the pages under the secure section of the site should be made available only over SSL. Failure to conform with this guideline could expose sensitive content and functionality to unauthorized access either through interception during cleartext transmission or via unencrypted storage in log files. Programmer's must identify and isolate portions of the application designed to handle sensitive content and functionality and communicate it to the site administrator. The administrator must ensure that such sections are accessible over a SSL/TLS connection and HTTP requests to them are blocked.

Android relies on a security Provider to provide secure network communications. However, from time to time, vulnerabilities are found in the default security provider. To protect against these vulnerabilities, Google Play services provides a way to automatically update a device's security provider to protect against known exploits. By calling Google Play services methods, your app can ensure that it's running on a device that has the latest updates to protect against known exploits.

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

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

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

The application uses an OAuth2 grant that is considered insecure and has known security weaknesses.

Specifically, the code uses the password grant, which insecurely exposes the credentials of the resource owner to the client and unnecessarily increases the attack surface.

Example 1: The following application.properties configuration file uses the OAuth2 password grant.

...
spring.security.oauth2.client.registration.clientID.authorization-grant-type=password
...

Always treat the social security number (SSN) as private information. This information is susceptible to theft if it is transmitted, stored, or processed in an unsafe manner. Access to legitimate social security numbers can lead to identity theft.

Privacy violation occurs when:
1. A social security number enters the program.

2. The social security number is written to an external location, such as the console, file system or network.

Transmitting social security numbers over an unencrypted channel, hardcoding them inside the application code, unencrypted storage of social security details in insufficiently protected back up files are some of the potential causes that could allow an attacker to gain access to a victim's SSN.

The SSN information could either be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging practice could also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk.

Collection and management of private information is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Privacy violations occur when:

1. Private information enters the program.
2. The data is written to an external location, such as the console, file system or network.

Example 1: The following code defines a password parameter without the @secure() decorator.

@description('Provide the password')
param password string

The code in Example 1 will result in the password parameter being saved to the deployment history and logs.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

A <forward> tag must have name and path attributes. Without a name, the forward will never be used.

Example 1: The following <forward> tag has an empty name attribute.

    <forward name="" path="/results.jsp"/>