jQuery user interface framework
Last few years a bunch of new HTTP headers were added to the web platform. The purpose of this blog post is to discuss the most critical headers from a security perspective.
This http header helps avoiding clickjacking attacks. Browser support is as follow: IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Posible values are:
// Raw header
X-Frame-Options: sameorigin
// How to send the response header with PHP
header("X-Frame-Options: sameorigin");
// How to send the response header with Apache (.htaccess)
<IfModule mod_headers.c>
Header set X-Frame-Options "sameorigin"
</IfModule>
// How to send the response header with Express.js
app.use(function(req, res, next) {
res.header("X-Frame-Options", "sameorigin");
next();
});
Note: The Content-Security-Policy HTTP header has a frame-ancestors
directive which obsoletes this header for supporting browsers.
Use this header to enable browser built-in XSS Filter. It prevent cross-site scripting attacks. X-XSS-Protection header is supported by IE 8+, Opera, Chrome, and Safari. Available directives:
// Raw header
X-XSS-Protection: 1; mode=block
// How to send the response header with PHP
header("X-XSS-Protection: 1; mode=block");
// How to send the response header with Apache (.htaccess)
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
// How to send the response header with Express.js
app.use(function(req, res, next) {
res.header("X-XSS-Protection", "1; mode=block");
next();
});
This http header is supported by IE and Chrome, and prevents attacks based on
MIME-type mismatch. The only possible value is nosniff. If your
server returns X-Content-Type-Options: nosniff in
the response, the browser will refuse to load the styles and scripts in case
they have an incorrect MIME-type. The list with available MIME-types for styles
and scripts is as follow:
// Raw header
X-Content-Type-Options: nosniff
// How to send the response header with PHP
header("X-Content-Type-Options: nosniff");
// How to send the response header with Apache (.htaccess)
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>
// How to send the response header with Express.js
app.use(function(req, res, next) {
res.header("X-Content-Type-Options", "nosniff");
next();
});
So if you try to load for example a HTML document as external script resource
(the src attribute of HTMLScriptElement), the browser will refuse it.
To take advantage of this security header, the current webpage must be accessed over HTTPS. In this case the Strict-Transport-Security header force secure connections to the server. This prevents losing session data stored in cookies. Also prevents users to access website in case the server's TLS certificate is not trusted. Browser support: IE 11+, Chrome 4+, Firefox 4+, Opera 12+, Safari 7+. Accepts following directives:
// Raw header
Strict-Transport-Security: max-age=31536000
// or
Strict-Transport-Security: max-age=31536000; includeSubDomains
// How to send the response header with PHP
header("Strict-Transport-Security: max-age=31536000");
// How to send the response header with Apache (.htaccess)
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000"
</IfModule>
// How to send the response header with Express.js
app.use(function(req, res, next) {
res.header("Strict-Transport-Security", "max-age=31536000");
next();
});
This header could affect your website in many ways, so be careful when using it. The configuration below allows loading scripts, XMLHttpRequest (AJAX), images and styles from same domain and nothing else. Browser support: Edge 12+, Firefox 4+, Chrome 14+, Safari 6+, Opera 15+
Few notes: IE 10 and 11 supports CSP through the X-Content-Security-Policy header; Safari 5.1 supported through the X-Webkit-CSP header.
// Raw header
Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';
// How to send the response header with PHP
header("Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';");
// How to send the response header with Apache (.htaccess)
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';"
</IfModule>
// How to send the response header with Express.js
app.use(function(req, res, next) {
res.header("Content-Security-Policy", "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';");
next();
});
The Access-Control-Allow-Origin is part of the cross-origin resource sharing specification which we discussed recently.
The Public Key Pinning Extension for HTTP (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to prevent man-in-the-middle attacks with forged certificates. Currently, the HPKP header is deprecated and its support was removed.
Controls the value of Referer header sent with the additional requests for resources from a web page.
Firefox 36+ and Opera 15+ had a full support of the specification.
Edge 12+ and Safari 7.1+ supports the older draft of the spec with never, always, origin and default values.
Chrome 21+ does not support same-origin, strict-origin and strict-origin-when-cross-origin values.
Valid values are as follow:
// Raw header
Referrer-Policy: origin-when-cross-origin
// PHP
header("Referrer-Policy: origin-when-cross-origin");
// Apache
<IfModule mod_headers.c>
Header set Referrer-Policy "origin-when-cross-origin"
</IfModule>
// nginx
add_header Referrer-Policy "origin-when-cross-origin"
// Express.js
app.use(function(req, res, next) {
res.header("Referrer-Policy", "origin-when-cross-origin");
next();
});
Certificate Transparency policy means that user-agents, e.g. browsers should block an access
to a website with a certificate that is not registered in public CT logs (after October 2017).
Omitting the enforce directive will make it work only in report-only mode. In the
other side, the report-uri directive is meaningless when used together with the
enforce directive.
// Raw header
Expect-CT: max-age=7776000, enforce, report-uri="http://domain.com/ct-report"
// PHP
header("Expect-CT: max-age=7776000, enforce");
// Apache
<IfModule mod_headers.c>
Header set Expect-CT "max-age=7776000, enforce"
</IfModule>
// nginx
add_header Expect-CT "max-age=7776000, enforce"
// Express.js
app.use(function(req, res, next) {
res.header("Expect-CT", "max-age=7776000, enforce");
next();
});
The Feature-Policy header gives a site owners an opportunity to enable and disable specific browser features and APIs. This is a list of currently supported features:
NB » Recently, this header was renamed to Permissions-Policy in the spec.
To control the origins use the following values:
Feature-Policy: camera 'none'; fullscreen 'self'; geolocation *; microphone 'self' https://example.com
This specification used to be named Feature Policy. This is a list of currently policy-controlled features:
Permissions-Policy: camera=(), fullscreen=self, geolocation=*, microphone=(self "https://example.com")
The Clear-Site-Data header clears browser data for requested origin. The following directives are supported:
Clear-Site-Data: "cache", "cookies", "storage"
The HTTP Cross-Origin-Resource-Policy response header conveys a desire that the browser blocks no-cors cross-origin/cross-site requests to the given resource. Supported directives are:
Cross-Origin-Resource-Policy: same-site
The HTTP Cross-Origin-Embedder-Policy (COEP) response header prevents a document from loading any cross-origin resources that don't explicitly grant the document permission (using CORP or CORS). Supported directives are:
Cross-Origin-Embedder-Policy: require-corp
The HTTP Cross-Origin-Opener-Policy (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents. Supported directives are:
same-origin or same-origin-allow-popups.unsafe-none.Cross-Origin-Opener-Policy: same-origin
Big players as Google+, Facebook, Twitter, LinkedIn use the above HTTP headers as an additional layer on a defence of their architecture. So it's strongly recommended the use of security HTTP headers to make your website safer and resist of attacks. Do you want to know how secure is your website? Let's find out with a quick scan of your server response using our Headers Inspector tool.
Thanks so much for reading! If you have questions about HTTP security please drop a comment below. Don't forget to share too.
Join our mailing list and stay tuned! Never miss out news about Zino UI, new releases, or even blog post.
Comments are closed