The X-XSS-Protection header is typically enabled by default in modern browsers. When the header value is set to false (0), cross-site scripting protection is disabled.

The header can be set in multiple locations and should be checked for both misconfiguration as well as malicious tampering.

Example 1: The following code configures a Spring Security protected application to disable XSS protection:

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>

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.

HTTP headers are key-value pairs sent between the client and server to provide additional information for handling HTTP requests and responses. Browser vendors mark some HTTP headers as deprecated when they no longer maintain, support, or enhance implementation of the header. Usage of these headers might create a false sense of security and increase the site's vulnerability.

Developers should rely on HTTP headers specified in the HTML standard[3] as they are supported uniformly across browsers. Using non-standard headers might provide additional features and controls but comes with limited browser support and risk of deprecation.

For example, the X-XSS-Protection header was used by developers to control the browser's behavior and offer protection against cross-site scripting (XSS). Modern browsers have better built-in protections with the use of Content Security Policy. Therefore, relying on X-XSS-Protection header can introduce new risks.

One of the features of HTML5 is the ability to store data in a client-side SQL database. The main piece of information required to start writing to and reading from the database is its name. Therefore, it is crucial that the name of the database is a unique string that differs from user to user. If the name of the database is easy to guess, unauthorized parties, such as other users, might be able to steal sensitive data or corrupt the database entries.
Example 1: The following code uses an easy-to-guess database name:

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

This code will run successfully, but anyone who can guess the database name to be 'mydb' can access it.

HTML5 provides a new ability to do simple input form fields validation. One can specify whether an input form field is required by using the required attribute. Specifying the field type makes sure that the input is checked against its type. One can even supply a customizable pattern attribute that checks the input against a regular expression. However, this validation gets disabled when adding a novalidate attribute on a form tag and a formnovalidate attribute on a submit input tag.

Example 1: The following sample disables form validation via a novalidate attribute.

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

Example 2: The following sample disables form validation via a formnovalidate attribute.

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

HTML forms with disabled validation are not user-friendly and can potentially expose the server to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection.

It has become important to enforce the data privacy of a given web document due to the existance of side-channel exploits that result from vulnerabilities such as Spectre and Meltdown. The Cross-Origin Opener Policy (COOP) was created to help prevent sensitive information exposure due to side-channel attacks. Specifically, the COOP can enforce isolation of a document's browsing context group in regard to other external documents, such as popups.

Example 1: The following code shows an unsecure COOP setting of 'unsafe-none' in the Django framework. This might allow an external document to access the private data of a source document's browsing context group due to a side-channel attack.

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

MIME sniffing is the practice of inspecting the content of a byte stream to deduce the file format of the data within it.

If MIME sniffing is not explicitly disabled, attackers can manipulate some browsers into interpreting data in a way that is not intended, allowing for cross-site scripting attacks. For each page that could contain user-controllable content, you should use the HTTP header X-Content-Type-Options: nosniff.

Example 1: The following code configures a Spring Security protected application to disable MIME sniffing protection:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

Content Security Policy (CSP) is a declarative security header that allows 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. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of fifteen directives including eight that control resource access, namely: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Each of these takes a source list as a value specifying domains the site is allowed to access for a feature covered by that directive. Developers may use wildcard * to indicate all or part of the source. None of the directives are mandatory. Browsers will either allow all sources for an unlisted directive or will 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 the 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 might misconfigure this header.

Consider the following misconfiguration scenarios:

- Directives with unsafe-inline or unsafe-eval defeats the purpose of CSP.
- script-src directive is set but no script nonce is configured.
- frame-src is set but no sandbox is configured.
- Multiple instances of this header are allowed in same response. A development team and security team might both set a header but one may use one of the deprecated names. While deprecated headers are honored if a header with the latest name (that is, Content Security Policy) is not present, they are ignored if a policy with content-security-header name is present. Older versions only understand deprecated names, hence, in order to achieve desired support it is essential that the response include an identical policy with all three names.
- If a directive is repeated within the same instance of the header, all subsequent occurrences are ignored.

Example 1: The following django-csp configuration uses unsafe-inline and unsafe-eval insecure directives to allow inline scripts and code evaluation:

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

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.

Spring Security and other frameworks do not add Content Security Policy headers by default. The web application author must declare the security policy/policies to enforce or monitor for the protected resources to benefit from this additional layer of security.

Allowing your website to be added to a frame can be a security issue. For example, it may lead to clickjacking vulnerabilities or allow undesired cross-frame communications.

By default, frameworks such as Spring Security include the X-Frame-Options header to instruct the browser whether the application should be framed. Disabling or not setting this header can lead to cross-frame related vulnerabilities.

Example 1: The following code configures a Spring Security protected application to disable the X-Frame-Options header:

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>

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>

Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, exercise caution when defining the header because an overly permissive CORS policy can enable a malicious application to inappropriately communicate with the victim application, which can lead to spoofing, data theft, relay, and other attacks.

Example 1: The following is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Using the * as the value of the Access-Control-Allow-Origin header indicates that the application's data is accessible to JavaScript running on any domain.

One of the new features of HTML5 is cross-document messaging. The feature allows scripts to post messages to other windows. The corresponding API allows the user to specify the origin of the target window. However, caution should be taken when specifying the target origin because an overly permissive target origin will allow a malicious script to communicate with the victim window in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following example uses a wildcard to programmatically specify the target origin of the message to be sent.

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

Using the * as the value of the target origin indicates that the script is sending a message to a window regardless of its origin.

Browsers do not send the referrer header by default with requests originated from HTTPS to unencrypted HTTP links. However, when a request destination is also HTTPS, the header is sent regardless of the origin. A developer might leave sensitive information in URLs, which are exposed to third-party sites via the referrer header. The Referrer-Policy header is introduced to control browser behavior related to the referrer header. The Unsafe-URL option removes all restrictions and sends the referrer header with every request.

Example 1: The following code configures a Spring Security protected application to disable the default secure the referrer policy:

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

Sensitive information persisted using HTML5 storage objects are stored on the client-side. While this option might seem attractive from a performance perspective, any information stored on the client is easily accessible and can pose a security risk if it is accessed by an unauthorized third party.
Storing sensitive information in the localStorage or sessionStorage objects provided by HTML5 is not a secure. While this information might not be visible to a naive user, a technically savvy person could easily retrieve this data from a browser. If an application exhibiting this behavior is used in a publicly accessible computer, then a malicious user can steal any data stored on the client.

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>

HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks. By submitting additional parameters to a web application, and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together


For example:
- ASP.NET/IIS uses all occurrences of the parameters
- Apache Tomcat uses only the first occurrence and ignores others
- mod_perl/Apache converts the value into an array of values

Example 1: Depending on the application server and the logic of the application itself, the following request might cause confusion to the authentication system and allow an attacker to impersonate another user.
http://www.example.com/login.php?name=alice&name=hacker

Example 2: The following code uses input from an HTTP request to render two hyperlinks.

    ...
    String lang = request.getParameter("lang");
    GetMethod get = new GetMethod("http://www.example.com");
    get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
    get.execute();
    ...

URL: http://www.example.com?poll_id=4567
Link1: <a href="http://www.example.com/vote.php?lang=en&poll_id=4567">English<a>
Link2: <a href="http://www.example.com/vote.php?lang=es&poll_id=4567">Spanish<a>

The programmer has not considered the possibility that an attacker could provide a lang such as en&poll_id=1, and then the attacker will be able to change the poll_id at will.

An application's authentication and authorization mechanisms can be bypassed with HTTP verb tampering when:
1) It uses a security control that lists HTTP verbs.
2) The security control fails to block verbs that are not listed.
3) The application updates its state based on GET requests or other arbitrary HTTP verbs.



Most Java EE implementations allow HTTP methods that are not explicitly listed in the configuration. For example the following security constraint is applied to the HTTP GET method but not to other HTTP verbs:

    <security-constraint>
        <display-name>Admin Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Area</web-resource-name>
            <url-pattern>/pages/index.jsp</url-pattern>
            <url-pattern>/admin/*.do</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>only admin</description>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

Since verbs like HEAD are not explicitly defined in an <http-method> tag in this configuration, it might be possible to exercise administrative functionality by substituting GET or POST requests with HEAD requests. For HEAD requests to exercise administrative functionality, condition 3 must hold - the application must carry out commands based on verbs other than POST. Some web/application servers will accept arbitrary non-standard HTTP verbs and respond as if they were given a GET request. If that is the case, an attacker would be able to view administrative pages by using an arbitrary verb in a request.

For example, a typically client GET requests looks like:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com

In an HTTP Verb Tampering attack, an attacker would substitute GET with something like FOO

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com

At its core, this vulnerability is the result of an attempt to create a deny list--a policy that specifies what users are not allowed to do. Deny lists rarely achieve their intended effect.

Functions that search for characters within a buffer can return a pointer outside the bounds of the buffer provided under either of the following circumstances:

- A user controls the contents of the buffer to be searched.

- A user controls the value for which to search.

Example 1: The following short program uses an untrusted command-line argument as the search buffer in a call to rawmemchr().

int main(int argc, char** argv) {
  char* ret = rawmemchr(argv[0], 'x');
  printf("%s\n", ret);
}

The program is meant to print a substring of argv[0], but it might end up printing some portion of memory located above argv[0].

This issue is similar to a string termination error, where the programmer relies on a character array to contain a null-terminator.

This class has been annotated with the annotation Immutable, from the JCIP annotations package. However, one of the mutable fields of the class had a mutating method called on it outside of the constructor and destructor.

Example 1: The following code for an immutable final class declares a Set private and final, then mistakenly creates a method that mutates the Set.

@Immutable
public final class ThreeStooges {
  private final Set stooges = new HashSet>();
  ...

  public void addStooge(String name) {
    stooges.add(name);
  }
  ...
}