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.

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

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_CLASSES = (
    ...
    '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.