https://securityheaders.com/ reports your site is not as secure as could be.

Scott Helme provides a lot of information about the headers that securityheaders.com tests for as links directly from the generated report. Implementation of some of the headers is certainly more straightforward than others.

X-Frame-Options

Valid values in order of preference:

• deny
  The browser will not allow your site to be loaded inside a frame
• sameorigin
  Allows you to frame your own site
• allow-from https://<host>
  Allows the site at <host> to frame your site

Consider if your site needs to be framed at all. Specific pages could use a different value for X-Frame-Options as needed.

Strict-Transport-Security

max-age=31536000; [includeSubDomains]

Instructs the browser to only connect using https for the next year (31536000 seconds). Optionally also consider all subdomains as HSTS hosts.

X-XSS-Protection

1; [mode=block]

Enables the browsers XSS protection. mode=block will block the request entirely, otherwise the browser tries to sanitise the response.

X-Content-Type-Options

nosniff

Instructs the browser to accept the content-type header and not sniff the payload to determine what is being sent.

Referrer-Policy

Consider if your site exposes sensitive information in the url, if it reads the referer anywhere for internal navigation or if other sites depend on specific information in the url.

Content-Security-Policy

Content Security Policy defines the hosts from which the browser can load frames, images, css, scripts etc. A default-src can be provided to obviate the need for a 'self' on every rule.

The script-src is probably the most difficult to set properly. For a properly secure site you would want to block 'unsafe-inline' and 'unsafe-eval', but many sites use inline script (which includes onevent attributes on DOM elements) and jQuery relies heavily on eval().

Inline script blocks can be allowed by using a nonce, which must be declared in the CSP header and should be a different string on each new request, or a hash (but if you know beforehand what your script will hash to, why not put the code in an include). Event handlers should be added to the desired elements from script instead of from attributes.

If your site relies on jQuery, 'unsafe-eval' will have to be allowed. There are ways to minimize the risk of jQuery evals in your site. For instance, Dropbox has a security patch available, described here.

The CSP attribute "frame-ancestors" works similar to X-Frame-Options.

The CSP attribute "object-src" should be set to "self", as at least Chrome checks it before opening pdf files.

Feature-Policy

Allows the listed features for * (all), 'self', 'none' or specific origins:

• geolocation
• midi
• notifications
• push
• sync-xhr
• microphone
• camera
• magnetometer
• gyroscope
• speaker
• vibrate
• fullscreen
• payment
  
  

Only geolocation seems relevant, although sync-xhr is unclear to me.