Security headers are directives used by web applications to configure security defenses in web browsers. Based on these directives, browsers can make it harder to exploit client-side vulnerabilities such as Cross-Site Scripting or Clickjacking. Headers can also be used to configure the browser to only allow valid TLS communication and enforce valid certificates, or even enforce using a specific server certificate.
The sections below detail the various security headers and support for them in Deep Security:

Customizable security headers

The following headers can be enabled and configured based on specific environment requirements:
Note
Note
As the primary tenant, you can Enable customizable security headers in the Deep Security Manager or Reset your configuration.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security is a header that configures the web browser to always use a valid secure connection with the web application. If the server TLS certificate suddenly becomes expired or untrusted, the browser will no longer connect to the web application. Also, if the user attempts to access the web application using an http:// url, the browser will automatically change it to https://. These countermeasures help prevent Man-in-the-middle attacks as well as other attacks such as Session Hijacking.
On install, the Deep Security Manager console has a self-signed (untrusted) certificate and HSTS is turned off. This is because each organization must configure the Deep Security web application with a specific certificate that matches the manager hostname. This can also be achieved by configuring a Load Balancer with TLS termination such as AWS ELB/ALB.
Once a valid TLS configuration is in place, the HTTP Strict Transport Security Header can be enabled from Administration > System Settings > Security.
For instructions on enabling HTTP Strict Transport Security (HSTS), see Enable customizable security headers.

Content Security Policy (CSP)

Content Security Policy includes a comprehensive set of directives that help prevent client-side attacks, such as Cross-Site Scripting and Clickjacking, by restricting the type of content the browser is allowed to include or execute.
Enabling CSP can have adverse effects. For example, embedded scripts might stop working or certain types of images required by third-party components such as jQuery might not load.
When you enable CSP, it is always a good idea to run it in Report only first and observe if any violations are reported to the provided URL for expected application functionality.
The Deep Security CSP can be configured under Administration > System Settings > Security.
Deep Security works best with the following settings:
object-src 'self'
default-src 'self'
script-src 'self' 'unsafe-eval' 'unsafe-inline'
frame-src 'self'
frame-ancestors 'self'
style-src 'self' 'unsafe-inline' blob:
form-action 'self'
img-src 'self' data:
report-uri https://your_report_uri.org/DS_CSP_Violation
Note
Note
By default, the Report only check box is selected. Once you confirm that the CSP does not break the expected application functionality, you can deselect Report only to enforce the policy.
WARNING
WARNING
Currently, script-src does not support 'nonce' or 'harsh-algorithm'. If you have concerns about cross-site scripting (XSS), enable the Intrusion Prevention rule 1000552 - Generic Cross Site Scripting (XSS) Prevention.
For instructions on enabling Content Security Policy (CSP), see Enable customizable security headers.

HTTP Public Key Pinning (HPKP)

The HPKP header forces browsers to only trust a specific certificate or certificate authority for secure communications. This prevents attacks that leverage a trusted certificate authority which has been compromised or maliciously installed on the client.
Note
Note
Enabling HPKP can leave browsers unable to connect if a certificate is changed without its header also being changed.
For instructions on enabling HTTP Public Key Pinning (HPKP), see Enable customizable security headers.

Enable customizable security headers

In multi-tenant mode, security header settings are only available to the primary tenant.
  1. Go to Administration > System Settings > Security.
  2. Enter your HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), or HTTP Public Key Pinning (HPKP) directive(s) in the corresponding field(s).
    Note
    Note
    Before you enable settings, you can test them by selecting the Report Only option and verifying that the policy violation reports are correct.
    Tip
    Tip
    You can enter individual policy directives on separate lines.
  3. Click Save at the bottom of the page.

Reset your configuration

If you experience trouble while configuring your directive and cannot correct it in the Deep Security Manager, SSH into the manager and run the corresponding commands to reset your configuration:

HTTP Strict Transport Security

dsm_c -action changesetting -name settings.configuration.enableHttpStrictTransportSecurity -value ""
dsm_c -action changesetting -name settings.configuration.enableHttpStrictTransportSecurity -value "false"

Content Security Policy

dsm_c -action changesetting -name settings.configuration.contentSecurityPolicy -value ""
dsm_c -action changesetting -name settings.configuration.contentSecurityPolicyReportOnly -value "true"

Public Key Pinning Policy

dsm_c -action changesetting -name settings.configuration.publicKeyPinPolicy -value ""
dsm_c -action changesetting -name settings.configuration.publicKeyPinPolicyReportOnly -value "true"

Enforced security headers

The following headers are enforced by default and cannot be changed:

Cache-Control and Pragma

These headers configure how the browser caches content. Caching sensitive content from an authenticated application can be a security vulnerability if the content is cached on a machine that is used by multiple users or if an attacker gains access to an unlocked machine after the user has logged out of the application. For this reason, Deep Security disables caching on all content that is not static by enforcing the no-cache and no-store values.

X-XSS-Protection

This XSS-Protection header forces the browser's Cross-Site Scripting (XSS) heuristics to detect XSS attacks. Deep Security enforces this header in block mode by default. This means that if the browser detects a potential XSS attack it will stop the page from loading altogether—a safer approach than the alternative of trying to sanitize the page by replacing potentially malicious elements.
XSS-Protection does not work for all types of attacks and not all browsers have an XSS filter.

X-Frame-Options

This header helps to prevent Clickjacking attacks. The Deep Security Manager enforces the SAMEORIGIN value for this header, only allowing it to be embedded in web applications that are hosted on the same domain.
This header has the same effect as the frame-ancestors CSP directive. The frame-ancestors directive will override the value of the X-Frame-Options header.

Unsupported security headers

The following header type is unsupported.

X-Content-Type-Options

This header with the nosniff value helps protect against mime type sniffing. Mime type sniffing attacks are only effective in specific scenarios where they cause the browser to interpret text or binary content as HTML. For example, if a user uploads an avatar file named xss.html and the web application does not set a Content-type header when serving the image, the browser will try to determine the content type and will likely treat xss.html as an HTML file. The attacker can then direct users to xss.html and conduct a Cross-Site Scripting attack.
Deep Security does not currently support enabling this header as it has been observed to cause adverse effects on redirects, however the relevant attack scenarios are not likely to impact the manager web application and its usual functionality.