Is your website's security covered by GDPR? HTTPS, security headers and Article 32

When data protection comes up, most site owners think of documents: the privacy notice, the cookie policy, consent. The GDPR also looks at how you protect the data you collect. If your contact form runs over an unencrypted connection, carefully written documents do not close that gap.

This article covers the security layer of your site that can be seen from outside: HTTPS and the certificate, security headers and external scripts. What happens inside the server, backups and access rights are outside the scope of this article.

The sources are the text of the GDPR and the guidance published by the CNIL, the French data protection authority, and by ANSSI, the French national cybersecurity agency. The test the GDPR sets is that a measure is appropriate to the risk and is checked regularly. The guidance shows what that test looks like on a website.

Why security is a data protection matter

Article 5 of the GDPR lists the principles for processing personal data. One of them is integrity and confidentiality: data has to be processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.

The same article sets out the accountability principle: the controller has to be able to demonstrate compliance with those principles. In practice that means being able to show which measure you took and how you check it.

What Article 32 asks for

Article 32 sets a test. The controller and the processor take into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk to the rights and freedoms of individuals, and implement technical and organisational measures that ensure a level of security appropriate to that risk.

The article names four examples: the encryption of personal data and keeping it in a form that cannot be attributed to a person without additional information (pseudonymisation), the ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore access to data in a timely manner after an incident, and a process for regularly testing and evaluating the effectiveness of the measures.

When a security incident leads to a personal data breach, a separate duty applies. Under Article 33 the controller notifies a personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it. The notification is not required where the breach is unlikely to result in a risk to the rights and freedoms of individuals.

Where personal data travels on your site

The GDPR defines personal data as any information relating to an identified or identifiable natural person. A name, location data and online identifiers appear in the article as examples. Even a small brochure site usually carries data that falls under this definition:

• Contact and quote forms: name, email address, phone number, the message itself.
• Registration and login pages: username, password, session details.
• Order and payment steps: address and payment details.
• Newsletter sign-ups and application forms.

The first step is to list these points. Without knowing which pages carry a form, and which external services run on those pages, you cannot judge whether the measure you took is appropriate to the risk. By scanning your site you can see the third-party services running on your pages.

HTTPS: encryption in transit

HTTPS encrypts the connection between the visitor's browser and your site. The CNIL lists implementing TLS on all websites, using only the most recent versions, among its basic precautions. According to the guide, TLS should be mandatory on authentication pages and on every page where personal data is displayed or transmitted.

In everyday language people still say SSL certificate, but TLS is the protocol that replaced SSL. ANSSI's TLS guide recommends not using SSLv2, SSLv3, TLS 1.0 and TLS 1.1, preferring TLS 1.3, and accepting TLS 1.2 under the conditions the guide sets out. ANSSI considers it necessary to apply these recommendations to every site, including sites that do not handle sensitive information.

As ANSSI points out, sites often accept HTTP connections and redirect them to HTTPS, which leaves an attacker the opportunity to intercept that connection. ANSSI considers the HSTS header necessary for this: it tells the browser to use HTTPS for every access to the site. The browser learns this rule on its first visit to the site. ANSSI notes that, to cover the first visit too, a site can be registered on a list that browsers know in advance.

What happens when the certificate is invalid

Every certificate has a validity period. As ANSSI describes, browsers raise a security alert when they meet an invalid certificate. If HSTS is defined, the visitor cannot click past that alert and continue to the site.

For this reason ANSSI treats lasting HTTPS access as an indispensable prerequisite for HSTS. The CNIL also lists obtaining certificates at the appropriate level, and managing them adequately, among its basic precautions. ANSSI further recommends monitoring Certificate Transparency logs in order to detect illegitimate certificates issued for your domain.

What security headers do

Security headers are instructions your server sends to the browser along with the response. The visitor does not see them, but they decide how the browser handles the page. ANSSI's guide on browser-side security standards recommends these in particular:

• Strict-Transport-Security (HSTS): makes the browser connect to the site over HTTPS.
• Content-Security-Policy (CSP): limits the sources a page may load content from, using an allowlist.
• Frame protection: the frame-ancestors setting inside CSP restricts your page from being shown inside a frame on another site and protects against clickjacking. ANSSI also recommends the X-Frame-Options header as additional protection.
• Referrer-Policy: limits the address information the browser sends to another site. ANSSI recommends not keeping the default behaviour.

The CNIL also lists applying the Secure and HttpOnly options to all cookies in use among its basic precautions.

The security side of external scripts

The code of an analytics tool, or of a library loaded from a content delivery network, does not sit on your server. For sites on HTTPS, ANSSI recommends applying integrity checks (Subresource Integrity) systematically, in particular for resources coming from content delivery networks. If the file does not match the expected hash, the browser blocks it. According to the guide, this check only works on CSS and JavaScript files and generally requires resources whose address contains a version number.

ANSSI also notes that a content security policy can be used to make sure advertising and traffic analysis scripts are absent from pages where sensitive data such as passwords or banking details is entered. The CNIL's basic precaution points the same way: limit the number of components in use, keep watch over them and keep them updated.

Regular testing

Article 32 also names a process for regularly testing and evaluating the effectiveness of the measures. For software running on servers, the CNIL advises using vulnerability detection tools for the most critical processing. According to the guide, these tests should be carried out regularly and before any new software version goes into production.

When a new plugin is installed or hosting is moved, the settings can change too. Repeating the check at set intervals and keeping the result also makes it easier to show which measure you checked, and when. The features page shows how scheduled scanning works.

Five frequent mistakes

• Turning HTTPS on only for the login or payment page and leaving the other pages unencrypted.
• Continuing to accept HTTP connections without defining HSTS.
• Letting the certificate become invalid on a site that has HSTS defined.
• Loading external scripts on every page, pages with forms included, without integrity checks.
• Configuring security once at launch and never checking it again.

Checklist

• Do you have a list of the pages on your site that collect personal data?
• Do all pages open over HTTPS?
• Does your server refuse SSLv2, SSLv3, TLS 1.0 and TLS 1.1 connections?
• Who keeps track of your certificate's expiry date, and how?
• Are the HSTS, Content-Security-Policy, frame protection and Referrer-Policy headers defined?
• Are the Secure and HttpOnly options set on your cookies?
• Is your list of external scripts up to date, and have the ones that are not needed been removed from pages with forms?
• Are these checks repeated at regular intervals, and are the results kept?

Most items on this list can be checked by looking at your site from outside. DILAYS scans your site and shows the findings for SSL, DNS, security headers and cookies separately. You decide which measure is appropriate to your risk.