Results for https://svn.eionet.europa.eu/

HTTPS by default

svn.eionet.europa.eu uses HTTPS by default.

Chromium reports the following:

Title	Summary	Description
Certificate	valid and trusted	The connection to this site is using a valid, trusted server certificate issued by GoGetSSL RSA DV CA.
Connection	secure connection settings	The connection to this site is encrypted and authenticated using TLS 1.2, ECDHE_RSA with X25519, and AES_128_GCM.
Resources	all served securely	All resources on this page are served securely.

More information about the site's TLS/SSL configuration:

How to implement

To enable HTTPS on a website, a certificate for the domain needs to be installed on the web server. To get a certificate that browsers will trust, you need one issued by a trusted certificate authority (otherwise a visitor's browser will show a warning).

Let's Encrypt is a non-profit certificate authority (sponsored by Mozilla, EFF, Cisco, Facebook and others) providing free certificates through an easy, automated process. You can set it up yourself, or use one of the many hosting providers who have built-in support for Let's Encrypt.

Get started with Let's Encrypt
Mozilla SSL/TLS Configuration Generator [for advanced users]
For checking the configuration of a server, try SSL Labs SSL Server Test (web), testssl.sh (CLI tool), Mozilla TLS Observatory (CLI tool) or Observatory by Mozilla (web).

HTTPS encrypts nearly all information sent between a client and a web service. Properly configured, it guarantees three things:

Confidentiality. The visitor's connection is encrypted, obscuring URLs, cookies, and other sensitive metadata.
Authenticity. The visitor is talking to the "real" website, and not to an impersonator or through a "man-in-the-middle".
Integrity. The data sent between the visitor and the website has not been tampered with or modified.

A plain HTTP connection can be easily monitored, modified, and impersonated. Every unencrypted HTTP request reveals information about a userâs behavior, and the interception and tracking of unencrypted browsing has become commonplace.

The goal of the Internet community is to establish encryption as the norm, and to phase out unencrypted connections.

GDPR: Rec. 83, Art. 5.1.f, Art. 25, Art. 32.1
By GDPR Art. 25, a controller is responsible for implementing state of the art data protection by design and by default. Encrypted connections are a well-established technology to protect the privacy of web visitors against eavesdroppers on the wire.

HTTP Strict Transport Security (HSTS)

HSTS policy for https://svn.eionet.europa.eu:
max-age=15724800; includeSubDomains

Pass	Test
	`max-age` set to at least 6 months
	`includeSubDomains` — policy also applies to subdomains
	`preload` — requests inclusion in preload lists [only relevant for base domain]

HSTS not set on base domain https://europa.eu.

How to implement

HSTS is just an HTTP header. In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds (the policy is refreshed every time browser sees the header again):

Strict-Transport-Security: max-age=31536000;

In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be "preloaded" into browsers:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Note that includeSubDomains should be deployed at the base domain, i.e., https://example.com, not https://www.example.com. While we recommend the use of includeSubDomains, be very careful, as it means that all subdomains associated with the parent domain must support HTTPS. (They do not have to each have their own HSTS policy.)

For a user to take advantage of HSTS, their browser does have to see the HSTS header at least once. This means that users are not protected until after their first successful secure connection to a given domain.

To solve this problem, the Chrome security team created an "HSTS preload list": a list of domains baked into Chrome that get Strict Transport Security enabled automatically, even for the first visit.

Firefox, Safari, Opera, and Edge also incorporate Chromeâs HSTS preload list, making this feature shared across major browsers.

The Chrome security team allows anyone to submit their domain to the list, provided it meets a few requirements.

HTTP Strict Transport Security [cio.gov]
HSTS Preload List Submission [hstspreload.org]
Strict-Transport-Security [mozilla.org]

Text adapted from the CIO Council's The HTTPS-Only Standard (public domain).

Content Security Policy

Content Security Policy set in HTTP header:

Content Security Policy (CSP) header not implemented.

How to implement

The recommended way to enable Content Security Policy is with the Content-Security-Policy HTTP header, e.g.:

Content-Security-Policy: default-src 'self'

It can also be enabled with an HTML <meta> element:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

CSP is a powerful mechanism that we strongly recommend. It allows for very fine-grained control. However, creating a good policy (or adjusting your site to work with a good policy) can take some time and effort. To make this easier, it's possible to use CSP in report-only mode.

See the following pages for more information:

Content Security Policy (CSP) [developer.mozilla.org]
Google Web Fundamentals: Content Security Policy [developers.google.com]
CSP Cheat Sheet [scotthelme.co.uk]
Report URI: Tools (CSP analyser, CSP builder) [report-uri.com]
CSP Evaluator [csp-evaluator.withgoogle.com]
CSP Level 2 specification [w3.org]
CSP Level 3 specification [w3.org]
Browser support [caniuse.com]

The Content Security Policy tests are based on the ones from the Mozilla HTTP Observatory scanner/grader project (Mozilla Public License 2.0) by April King, reimplemented by us for Webbkoll. The explanatory texts are from the Observatory by Mozilla website, CC-BY-SA 3.0. Any mistake or inaccuracy in the results is our fault.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser's trust of the content received from the server. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from.

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes).

— MDN: Content Security Policy (CSP), Mozilla Contributors, CC BY-SA 2.5

GDPR: Rec. 83, Art. 5.1.f, Art. 25, Art. 32.2
GDPR Art. 32.2 makes clear that measures should be taken against unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed. CSP is a relatively simple way of ensuring that your web visitors do not end up being put in contact with someone that either they - or you - did not anticipate for them to contact.

Reporting (CSP, Certificate Transparency, Network Error Logging)

Reports are not sent to a third-party.

The Content Security Policy (CSP) directive report-uri, or report-to in combination with a Report-To header, instructs the user's browser to send a violation report to specified URI(s) if the CSP is violated. Each report is a JSON object containing information about the violation, including, among other things, the URL of the document where it occurred, and referrer information. While reporting is useful for developers to find and fix bugs, it can also be used for tracking purposes.

The Expect-CT header can be used to enforce Certificate Transparency requirements, and/or optionally send reports of Certificate Transparency violations to a specified URI.

The NEL (Network Error Logging) header instructs the user's browser to send reports about network errors (e.g. DNS resolution error, TCP or TLS connection failure, 4xx or 5xx HTTP responses) to a specified URI. It can also be configured to send reports about successful network requests. See [1], [2] for privacy considerations.

Referrer Policy

Referrer Policy not set. This means that the default value no-referrer-when-downgrade, leaking referrers in many situations, is used.

How to implement

A referrer policy can easily be set with a <meta> element in your HTML. Simply include this inside the <head> section:

<meta name="referrer" content="no-referrer">

Alternatively, set the Referrer-Policy HTTP header, e.g.:

Referrer-Policy: no-referrer

If a referrer policy is delivered via both Referrer-Policy header and meta element, the meta element's policy takes precedence.

If multiple policy values are specified, the browser will use the last one, ignoring unknown values (fallback values should thus appear first). Multiple values should be separated by commas, e.g.:

<meta name="referrer" content="no-referrer, same-origin">

Several policies are offered, such as origin (strips everything except the origin) and origin-when-cross-origin (sends full URL with same-origin requests, otherwise stripped). We recommend no-referrer, which kills the referrer header entirely for all requests, no matter the destination; or same-origin, which kills the referrer for third-party requests but not for requests to the same origin.

Referrer-Policy [developer.mozilla.org]
Referer header: privacy and security concerns [developer.mozilla.org]
Referrer Policy specification [w3.org]
Browser support [caniuse.com]

When you click on a link, your browser will typically send the HTTP referer [sic] header to the webserver where the destination webpage is at. The header contains the full URL of the page you came from. This lets sites see where traffic comes from. The header is also sent when external resources (such as images, fonts, JS and CSS) are loaded.

The referrer header is privacy nightmare as it allows websites and services to track you across the web and learn about your browsing habits (and thus possibly private, sensitive information), particularly when combined with cookies.

By setting a Referrer Policy, it's possible for websites to tell browsers to not leak referrers. Referrer Policy lets you specify a policy that's applied to all links clicked, as well as all other requests generated by the page (images, JS, etc.).

GDPR: Rec. 83, Art. 5.1.c, Art. 25, Art. 32.2
Setting referrer policy is an easy way to do data minimization (Art. 5.1.c) and help ensure that you don't transfer or disclose personal data needlessly (Art. 32.2).

Subresource Integrity (SRI)

Subresource Integrity (SRI) not implemented, but all resources are loaded from a similar origin.

How to implement

SRI can be used with script and link elements. To enable SRI on an element, you need to add integrity and crossorigin attributes to it.

integrity should contain integrity metadata: a string describing the cryptographic hash function used (currently sha256, sha384, or sha512), followed by a dash, followed by the base64-encoded hash of the file.

crossorigin must be set to anonymous for third-party resources when using SRI. This has to do with CORS.

For example, given the file https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js, we can calculate the SHA384 hash:

$ openssl dgst -sha384 -binary jquery.min.js | openssl base64 -A tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT

The correct HTML code should then be:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha384-tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT" crossorigin="anonymous"></script>

When the browser sees this element, it will download jquery.min.js, calculate the SHA384 hash, compare it to the hash in the integrity attribute, and only run the script if the hashes match. For example, if someone were to modify jquery.min.js on the remote server after we calculcated the original hash, Firefox would refuse to run the script and you'd see this in the browser console:

None of the âsha384â hashes in the integrity attribute match the content of the subresource.

To make all this easier, you can use Mozilla's SRI Hash Generator.

Subresource Integrity [developer.mozilla.org]
Protecting your embedded content with subresource integrity (SRI) [troyhunt.com]
Subresource Integrity specification [w3.org]
Browser support [caniuse.com]

The Subresource Integrity test is based on the one from the Mozilla HTTP Observatory scanner/grader project (Mozilla Public License 2.0) by April King, reimplemented by us for Webbkoll.

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.

Using Content Delivery Networks (CDNs) to host files such as scripts and stylesheets that are shared among multiple sites can improve site performance and conserve bandwidth. However, using CDNs also comes with a risk, in that if an attacker gains control of a CDN, the attacker can inject arbitrary malicious content into files on the CDN (or replace the files completely) and thus can also potentially attack all sites that fetch files from that CDN.

Subresource Integrity enables you to mitigate some risks of attacks such as this, by ensuring that the files your web application or web document fetches (from a CDN or anywhere) have been delivered without a third-party having injected any additional content into those files â and without any other changes of any kind at all having been made to those files.

— MDN, Subresource Integrity, Mozilla Contributors, CC BY-SA 2.5

GDPR: Rec. 83, Art. 5.1.f, Art. 25, Art. 32.2
This is an easy measure to take against unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.

HTTP headers

Pass	Header	Value	Result
	X-Content-Type-Options		X-Content-Type-Options header not implemented
	X-Frame-Options		X-Frame-Options (XFO) header not implemented
	X-XSS-Protection		X-XSS-Protection header not implemented

How to implement

To enable these headers you'll need to add them to your web server configuration. This is a simple change. Exactly how you do it depends on what server you use. This page [developer.mozilla.org] has configuration examples for Apache, Nginx and IIS.

X-Content-Type-Options should be set to nosniff, which is the only valid value.

X-Frame-Options can be set to deny (page can never be loaded in a frame), sameorigin (page can only be loaded in a frame only if the origin is the same), or allow-from <URI> (page can only be loaded in a frame on a page on the specified origin).

The old recommendation was to set X-XSS-Protection to 1 or 1; mode=block. However, OWASP now recommends setting it to 0.

X-Content-Type-Options [developer.mozilla.org]
X-Content-Type-Options HTTP Header [keycdn.com]
X-Frame-Options [developer.mozilla.org]
X-Frame-Options â How to Combat Clickjacking [keycdn.com]
X-XSS-Protection [developer.mozilla.org]
X-XSS-Protection - OWASP Cross Site Scripting Prevention Cheat Sheet [cheatsheetseries.owasp.org]

The header tests are based on the ones from the Mozilla HTTP Observatory scanner/grader project (Mozilla Public License 2.0) by April King, reimplemented by us for Webbkoll. The explanatory texts are from the Observatory by Mozilla website, CC-BY-SA 3.0.

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

— MDN, Content Security Policy (CSP), Mozilla Contributors, CC BY-SA 2.5

The X-XSS-Protection header has been deprecated by modern browsers and its use can introduce additional security issues on the client side. As such, it is recommended to set the header as X-XSS-Protection: 0 in order to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response.

— OWASP Cheat Sheet Series, Cross Site Scripting Prevention Cheat Sheet, OWASP CheatSheets Series Team, CC BY 3.0

GDPR: Art. 5.1.c, Art. 5.1.f, Art. 25, Art. 32.1-2.
These headers can help minimize data disclosures.

Cookies

No cookies detected.

GDPR: Rec. 60, Rec. 61, Rec. 69, Rec. 70, Rec. 75, Rec. 78, Art. 5.1.a, Art. 5.1.c, Art. 5.1.e, Art. 21, Art. 22, Art. 32.

e-PD (2002/58/EC). Rec. 24, 25, Art. 5.2.

e-PD revised (2009/136/EC). Rec. 65, 66.

More information

First-party cookies are placed by the web site owner in some register on their visitors' device in order to be able to re-identify the visitor on subsequent page loads. First-party cookies can be related to technical features on a web site (such as remembering language settings or the contents of a shopping basket), or related to commercial features of the web site owners' activities (such as being able to trace a visitors' behaviour over the duration of their visit, or over much longer time periods, often for years, in order to be able to serve advertisements to the users or to get usage statistics to guide later changes to the web site that are envisaged to make the web site more attractive to recurring users). First-party cookies may come from services provided by the web site owner (language settings in a Content Management System) or from services used by the web site owner (analytics tools).

Third-party cookies are placed by a service affiliated with the web site owner on the devices of visitors to the web site in order to be able to re-identity the visitor on subsequent page loads, or across different web sites. Third-party cookies are typically related to commercial features of a web site owners' activities, usually advertising, but may also relate to technical features in scripts used by a web site (such as language settings).

Storing information or gaining access to information stored in the visitors' devices, for instance in the form of cookies, has been subject to sui generis legislation in the European Union (ePD, Art. 5.3). These sui generis laws have tried to make a distinction between information stored to support technical features and information stored to support commercial features. In practice, poor enforcement of these rules has made the legal landscape unclear. Because there exists no legal duty for citizens to receive better targeted advertisement, nor a legal duty for citizens to assist web developers in improving web sites, it's doubtful that a legal basis exists for storing information to support commercial features without the consent of the web visitor (GDPR Art. 7). It is argued that the legitimate interests of a web site owner (Art. 6.1.f, Art. 6.4) may nevertheless enable them to subject a visitor to targeted ads or cause a visitor to assist the web developers. Then there must exist relevant and appropriate relationship between the web visitor and the web site owner in situations (GDPR Rec. 47), which calls into question the use of third-party service first-party cookies. In either case, if the legitimate interest legal basis for processing is invoked, adequate security measures must be undertaken (GDPR Art. 32).

Particular care must be taken with regards to the period of storage (GDPR Art. 5.1.e). While it is technically easy for a web site owner to set the duration of a information stored in the form of cookies to a long period time, the principle of storage limitation implies a balancing act between the interest of tracking a visitors' behaviour and the interest of the visitor to keep their behaviour private. It's been established that a reasonable storage period does not exceed one year.

localStorage

localStorage not used.

Third-party requests

No third-party requests.

A third-party request is a request to a domain that's not europa.eu or one of its subdomains.

GDPR: Rec. 69, Rec. 70, Art. 5.1.b-c, Art. 25.

Server location

Server location for svn.eionet.europa.eu (10.50.7.32) could not be determined.

See more information (e.g., provider) about this IP address using KeyCDN's tool.

Some sites use CDNs – content delivery networks – in which case the server location might vary depending on the location of the visitor. This tool, Webbkoll, is currently on a server in Finland.

Under the GDPR, all EU/EEA countries are considered equally trustworthy, so there is no particular reason under the GDPR to consider any EU country more or less reliable or desirable than any other. The importance of the location of a server comes into play only under GDPR Art. 23, Restrictions, where member states may invoke a number of reasons, notably national security, that enable them to void protections for visitors or web service providers.

For non-EU/EEA territories, it depends (GDPR Art. 44). For a website, transfers will probably have to rely on adequacy decisions (Art. 45) made by the European Commission when a third territory has been deemed to have appropriate data protection safe guards in its legislation. However, adequacy decisions cannot always be trusted, as demonstrated in the EU Court of Justice 2015 (C-362/14). Binding corporate rules (Art. 47) or standard clauses (Art. 46) may also be used to transfer data, but in the absence of rulings by courts and data protection authorities this is still legally uncertain territory.

Raw headers

Header	Value
accept-ranges	bytes
content-length	9031
content-type	text/html; charset=UTF-8
date	Wed, 01 May 2024 05:40:16 GMT
etag	"2347-5db5ad3e39400"
last-modified	Tue, 29 Mar 2022 12:47:12 GMT
strict-transport-security	max-age=15724800; includeSubDomains

What this tool checks (and doesn't check)

This tool attempts to simulate what happens when a user visits a specified page with a typical browser. The browser has no addons/extensions installed, and Do Not Track (DNT) is not enabled, since this is the default setting in most browsers.

External files such as images, scripts and CSS are loaded, but the tool performs no interactions with the page â no links are clicked, no forms are submitted.

Disclaimer: The results presented here might not be 100% correct. Bugs happen. This tool is meant to be used by site owners as a starting point for improvements, not as a rigorous analysis.

Text about HTTPS partly adapted from the CIO Council's The HTTPS-Only Standard (public domain). MaxMind's GeoLite2 country database (CC-BY-SA 4.0) is used for GeoIP lookups. See here for more information.

Results for svn.eionet.europa.eu

HTTPS by default

HTTP Strict Transport Security (HSTS)

Content Security Policy

Reporting (CSP, Certificate Transparency, Network Error Logging)

Referrer Policy

Subresource Integrity (SRI)

HTTP headers

Cookies

localStorage

Third-party requests

Server location

Raw headers

What this tool checks (and doesn't check)