Analysis of the adoption of security headers in HTTP

William J. Buchanan,Scott Helme,Alan Woodward

doi:10.1049/iet-ifs.2016.0621

William J. Buchanan, Scott Helme + Show 1 more

Open Access

https://doi.org/10.1049/iet-ifs.2016.0621

Copy DOI

Abstract

With the increase in the number of threats within web-based systems, a more integrated approach is required to ensure the enforcement of security policies from the server to the client. These policies aim to stop man-in-the-middle attacks, code injection, and so on. This study analyses some of the newest security options used within HTTP responses, and scans the Alexa Top 1 Million sites for their implementation within HTTP responses. These options scanned for include: content security policy, public key pinning extension for HTTP, HTTP strict transport security, and HTTP header field X-frame-options, in order to understand the impact that these options have on the most popular websites. The results show that, while the implementation of the parameters is increasing, it is still not implemented on many of the top sites. Along with this, the study shows the profile of adoption of Let's Encrypt digital certificates across the one million sites, along with a way of assessing the quality of the security headers.

Highlights

With HTTP, we have a request, such as GET request, and the server responds with a response
New security extensions have been added to prevent man-in-the-middle (MITM) attacks, such as the public key pinning extension for HTTP (HPKP) [7] and which allows a site to associate itself with specific cryptographic public keys and protects against forged digital certificates
New security extensions have been added to prevent MITM attacks, such as the HPKP [11] which allows a site to associate itself with specific cryptographic public keys and protects against forged digital certificates

Summary

Introduction

With HTTP, we have a request, such as GET request, and the server responds with a response. There are many standard application layer protocols that are used to exchange information, including HTTP [1], SMTP [2], FTP [3], and DNS [4]. These specifications were often written to support a simple text-based exchange of messages. Q4 While SSL and TLS purely protected the contents of the message exchange, the addition of CSP – content security policy – [6] integrates a policy language that sets content restrictions on a web resource, and where the server transmits the policy to the client, for it to enforce the policy. Response headers include: CSP, CSPRO, PKP, PKPRO, X-content-type-only, XFO, and XXP

Methods

Results

Conclusion