Instructs the browser to always request a domain using the HTTPS protocol instead of HTTP.
- Passive Network Attacks – man in the middle attacks, HTTPS stripping attacks.
- Active Network Attacks – compromised DNS, evil twin domains, etc.
- Mixed Content Vulnerabilities – loading of an insecure resource over a secure request (eg swf)
- Performance – removes unnecessary redirects to HTTPS from http.
- Because no one types https:// in the address bar.
max-age– number of seconds policy should be kept for.
includeSubDomains– apply this policy to all subdomains of the requested host. Omit to apply policy only to current domain.
Require HTTPS for 60 seconds on current domain:
Require HTTPS for 365 days on all subdomains:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Remove HSTS Policy (including subdomains):
Requests Over HTTP (Non Secure)
Must NOT respond with Strict-Transport-Security header on non-secure HTTP requests.
Requests Over HTTPS
- HSTS Specification: https://tools.ietf.org/html/rfc6797
- OWASP: HTTP Strict Transport Security Cheat Sheet
X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is
Allows the server to specify if the response content should be part of a frame, and if so from what origin.
frame-ancestors directive from the CSP Level 2 specification officially replaces this non-standard header but is not supported across all browsers. Though X-Frame-Options is not an official standard it is widely supported and can be used in conjunction with CSP.
- AKA UI Redressing
- Attacker tricks the user into clicking on something that performs an unintended action.
DENY– Specifies that the requested resource should never be embedded in a frame.
SAMEORIGIN– Only pages on the same domain may frame the requested resource.
ALLOW-FROM origin– Allow a whitelisted origin to frame the requested content.
HTTP Response header, allows server to control how resources are loaded.
- Greatly reduces success of Cross Site Scripting (XSS) attacks.
- Report / log xss attack attempts
CSP can protect against a variety of unauthorized asset types.
default-src– all assets (including scripts)
connect-src– XHR, WebSockets, EventSource
font-src– font files
frame-src– nested browsing contexts sources
img-src– limit origins of images
media-src– audio and video
object-src– Flash and other plugin objects
plugin-types– restricts the set of plugins that can be invoked
sandbox– preventing popups, the execution of plugins and scripts, and enforcing a same-origin policy
|*||Wildcard, allows all origins.|
|'self'||Allow same origin.|
|'none'||Don't allow any resources of this type to load.|
|domain.example.com||Allow a domain|
|*.example.com||Allow all subdomains on a domain.|
|data:||Allow data uri schemes.|
style-srcare enabled inline
tags are disabled.
- You can add
'unsafe-inline'to allow it, but defeats much of CSP's purpose.
- You can add
- You can add
'unsafe-eval'to a script-src directive to disable this.
- You can add
- Congure a report-uri to accept CSP exception requests (POST)
- Be notified of XSS vulnerabilities as they occur
- Users with CSP-supported browsers make it safer for everybody
Content-Security-Policy: default-src 'self'; report-uri http://example.com/report.php
- Notifies you of violations, but won't take action
- Lets you try CSP risk-free
report-urito receive JSON violation reports
Content-Security-Policy-Report-Only: default-src 'self'; report-uri http://example.com/report.php
- CSP quick reference
- W3C: Content Security Policy Level 2
- W3C: Content Security Policy Level 3
- OWASP: Content Security Policy Cheat Sheet
- Mozilla: CSP policy directives
A security mechanism that allows developers to explicitly enable or disable various powerful browser features for a given site.
- W3C: https://www.w3.org/TR/permissions-policy-1/
- W3C: Permissions Policy Explainer
The Referrer-Policy HTTP header governs which referrer information, sent in the Referrer header, should be included with requests made.
- Privacy –
no-referrer– Do not send a HTTP Referrer header.
no-referrer-when-downgrade– Send the origin as a referrer to URLs as secure as the current page, (https→https), but does not send a referrer to less secure URLs (https→http). This is the default behaviour.
same-origin– A referrer will be sent for same-site origins, but cross-origin requests will contain no referrer information.
origin– Send the origin of the document.
strict-origin– Only send the origin of the document as the referrer to a-priori as-much-secure destination (HTTPS->HTTPS), but don't send it to a less secure destination (HTTPS->HTTP).
origin-when-cross-origin– Send the full URL (stripped of parameters) for same-origin requests, but only send the origin for other cases.
strict-origin-when-cross-origin– Send a full URL when performing a same-origin request, only send the origin of the document to a-priori as-much-secure destination (HTTPS->HTTPS), and send no header to a less secure destination (HTTPS->HTTP).
unsafe-url– Send the full URL (stripped of parameters) for same-origin or cross-origin requests.
- W3C: Referrer Policy Specifications
- Mozilla: Referrer-Policy
Analyse the security of your HTTP response headers.
Analyse the Content Security Policy of your site or any other site.
Quickly and easily build your own Content Security Policy.
Generate a hash of your JS or CSS to include in your CSP.
Generate a SRI tag for externally loaded assets.