The script (and burp plugin) validates whether the headers pertaining to security are present and if present, whether they have been configured securely. It implements checks identified by

• https://securityheaders.io/
• https://csp.withgoogle.com
• OWASPs cheat sheets
• Original research

• Security Headers Checker
  • TL; DR
  • Table of Contents
  • Introduction
  • Installation and Execution
    • Using Docker
    • Using Burp
  • Security Headers
    • Content Security Policy
      • Specify default-src
      • Specify object-src, script-src, and base-uri
      • Avoid using unsafe-inline
      • Avoid using unsafe-eval
      • Avoid using the wild-card
      • Avoid specifying an IP source
      • Avoid using deprecated directives
      • Avoid using sources that start with http:
      • Avoid using sources that are untrusted
    • HTTP Strict Transport Security
      • Include the includeSubdomains directive
      • Avoid setting the max-age directive to 0
    • X-Frame-Options
      • Avoid using allow-from
    • X-Content-Type-Options
      • Avoid setting the header to anything other than nosniff
    • X-XSS-Protection
      • Avoid disabling the filter
      • Avoid using a HTTP report URI
      • Use block
    • Cross-Origin Resource Sharing
      • Avoid allowing access from all origins
      • Avoid using the null header with credentialed requests
      • Only allow HTTPS origins for requests with credentials
      • Avoid setting the preflight time for longer than 30 minutes
      • Avoid exposing sensitive headers
    • Referrer-Policy
      • Avoid using unsafe-url and origin-when-cross-origin
    • Feature-Policy
      • Avoid using the wild-card character
    • Other
    • Syntax Errors
  • References
    • Clear-Site-Data References
    • Content-Security-Policy References
    • CORS References
    • Feature-Policy References
    • HPKP References
    • HTTP-Strict-Transport-Security (HSTS) References
    • Referrer-Policy References
    • X-Frame-Options (XFO) References
    • X-Content-Type-Options References
    • X-Download-Options References
    • X-Permitted-Cross-Domain-Policies References
    • X-XSS-Protection References
  • TODOs

Applications can set secure HTTP response headers as an additional layer of defense that prevents browsers from running into easy preventable vulnerabilities. The script in this repository validates whether the headers pertaining to security are present and if present, whether they have been configured securely. In summary, the script implements the checks identified by

• https://securityheaders.io/
• https://csp.withgoogle.com
• original research

Make sure you have Python 2 or Python 3 installed. The current limitation of Python 3 is that the 'ScriptSrc'-style tags of the Content-Security-Policy are not analyzed.

Install the dependencies:

Start the script as follows.

Use the -h flag for all options.

In the example below, we execute the script to validate the headers of google.com.

By default the script will display all the response headers it received from the server. To not display those, execute the --skipheaders flag with the InfoCollector value.

The script also shows if security headers are missing. To disable those checks, add HeaderMissingChecker to the --skipheaders flag.

The script can show a list of supported checkers via the --listcheckers flag.

By default the script executes all of the listed checkers. Disable checkers with the --skipcheckers flag or execute specific checkers with the --checkers flag. If a checker has children, then the script skips or executes all the children checkers. In the example below, the script executes all checkers that find Content Security Policy issues, but skips the checkers that fire when the CSP header is missing.

By default the script shows the output in a tabular format. To create output in a different format, use the --formatter flag. In the example below, the script outputs the findings as CSV. Note that formatters base64-encode the fields that may contain control characters for that format. For instance, for CSV the description is base 64 encoded as it may contain commas.

To write output to a file rather displaying it on the screen, use the --file flag.

To check multiple websites, separate them with a comma.

To merge output into one table, use the --flatten flag. Avoid this if you are checking many (500k+) websites, as you may run out of memory.

To load URLs from a file, use a filename rather than a URL.

If the file is a CSV file, tell the column with URLs with the --urlcolumn flag (zero-indexed). To skip the CSV header row, use the --startrow flag.

To analyze a saved response, use the --response rather than a URL.

By passing a single dash (-) to --response the file will be read from sys.stdin

To supply headers directly, use the --headers and specify the headers separated with a newline.

For easy portablity, we added support for Docker for the cli tool.

Build the container:

Run the container:

Note: if you wish to add your own bypass files, use Docker volumes:

The checkers are also available as a BurpSuite plugin. The plugin does not display missing security headers or information about headers; i.e. it uses the --checker Checker --skipcheckers InfoCollector HeaderMissingChecker flags. Feel free to modify the code if you want to display those; I may or may not implement a configuration screen.

Install it as follows.

1. Go to Extender, Extensions, and click on Add Extension. Select python and load the burpecheaders.py file.
2. Once BurpSuite loads the plugin successfully, visit a website and observe that the plugin reports issues under the scanner tab.

Observe that the plugin highlights the offending header/directives/keywords in the response headers.

This section lists background information that help you understand the issues the tool reports. The reference section at the end of this README points you to more detailed information.

Security headers are HTTP headers that enable the server to influence the behavior of the browser from a security perspective. The remainder of this section describes security headers and their common insecure configurations.

A Content Security Policy (CSP) consists of a set of directives that restrict how a webpage loads resources, such as scripts and media files. The CSP protects a web page from various attacks, such as cross-site scripting (XSS) and clickjacking.

The directives that a CSP support include the following:

• default-src: this directive sets defaults for fetch directives (directives related to fetching of resources, such as scripts or style sheets). If none of the fetch directives have been defined in the policy, then the browser will enforce the default-src values. Valid values include the following ones.
  • : Only fetch media hosted by any of the specified hosts. The hosts can be IP-addresses, names, or names with the wildcard character (*).
  • : Only fetch media from URIs that match the specified schemas, such as http: or https:.
  • 'none': do no allow media of this type.
  • 'self': only fetch media hosted by the host sending this policy.
  • 'unsafe-inline': allow execution of inline code. An example would be code that exists in event handler or within script tags.
  • 'unsafe-eval': allow execution of code via eval functions, such as eval, setTimeout, setInterval, new Function, etc.
  • '-': allows developers to whitelist an inline script by specifying its hash as an allowed source of the script. If the hash matches, it is executed. This value is only available for CSP version 2 and above.
  • 'nonce-': allows developers to whitelist an inline script by sending a random nonce (generated for each request) as a potential script-src source. If the script-src has the same nonce, it is executed. This is only valid for CSP version 2 and above.
  • 'strict-dynamic': specifies that the trust given to one of the scripts with a nonce or hash is propagated to all the scripts loaded by that nonce/hash script, even if those loaded scripts do not match self or a whitelist.
• script-src: this directive determines valid sources of JavaScript.
• object-src: this directive determines where plugins can be loaded and executed from.
• style-src: this directive determines where CSS or style markup can be loaded from. This also supports nonces and hash values.
• img-src: this directive determines where images can be loaded from.
• media-src: this directive defines valid sources of audio and video, e.g. HTML5 .
• frame-src: this directive defines valid sources for loading frames.
• font-src: this directive defines valid sources of fonts.
• connect-src: this directive determines whether the web application can perform connections via XMLHttpRequest, WebSocket, or EventSource.
• sandbox: this directive specifies a sandbox policy for 'safely' embedding content into a sandbox.
• report-uri: this directive instructs the browser to post a report of policy failures to this URI. Deprecated in CSP version 3.
• report-to: This directive is the successor of report-uri (CSP Version 3).
• base-uri: this directive restricts the URLs that can be used to specify the document base URL. This URL determines the base for all relative URLs contained within a HTML document. Only from CSP version 2 and above.
• child-src: this directive defines valid sources for web workers and nested browsing contexts loaded using elements such as and