Website test: desec.io

We check if your domain name has at least two name servers with an IPv6 address.

This is consistent with the "Technical requirements for the registration and use of .nl domain names" d.d. 1 January 2023 by SIDN (.nl TLD registry) that require each .nl domain to have at least two name servers.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginning with ::ffff:) will fail in this test, as they do not provide IPv6 connectivity.

We check if there is at least one AAAA record with IPv6 address for your web server.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

We compare the available ports and offered headers and content of your web server via IPv6 with those via IPv4.

We check if:

1. the same ports, i.e. HTTP (port 80) and/or HTTPS (port 443), are available via both IPv6 and IPv4;
2. the same HTTP headers are offered via both IPv6 and IPv4. This includes HTTP response codes, like successful responses (200 – 299) and redirection messages (300 – 399). In cases of a client error response (400 - 499) or a server error response (500 - 599) a warning without score impact is given, because such a HTTP response code may indicate a configuration issue;
3. the same HTML content is offered via both IPv6 and IPv4. We do this by comparing the content received after stripping any nonces. The content difference must not be higher than 10% to pass this subtest. This threshold ensures that small non-problematic differences (for example due to changing advertisements) do not immediately result in a failing result for this subtest. An observed difference may still be intended or due to measurement error. Therefore, in case of failure, this part of the subtest results only in a warning with no score impact.

Additional notes:

• In case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest.
• If only an IPv6 address and no IPv4 address (or vice versa) is available, the subtest is not applicable because no comparison can be made.
• This subtest follows redirects and also checks all underlying URLs.

We check if your domain, more specifically its SOA record, is DNSSEC signed.

If a domain redirects to another domain via CNAME, then we also check if the CNAME domain is signed (which is conformant with the DNSSEC standard). If the CNAME domain is not signed, the result of this subtest will be negative.

Note: the validity of the signature is not part of this subtest, but part of the next subtest.

We check if your domain, more specifically its SOA record, is signed with a valid signature making it 'secure'.

If a domain name redirects to another signed domain name via CNAME, then we also check if the signature of the CNAME domain name is valid (which is conformant with the DNSSEC standard). If the signature of the CNAME domain name is not valid, the result of this subtest will be negative.

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be 'secure' one time and 'bogus' the next.

We check if your website is reachable over HTTPS.

If so, we also check in the below subtests whether HTTPS is configured sufficiently secure in conformance with the 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL.

HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user.

Note that for performance reasons all tests in the category 'Secure connection (HTTPS)' only run for the first available IPv6 and IPv4 address.

We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 30x redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

• http://example.org ⇒ https://example.org ⇒ https://www.example.org
• http://www.example.org ⇒ https://www.example.org

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See 'ICT security guidelines for web applications' from NCSC-NL, guideline U/WA.05 (in Dutch).

We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to Machine-in-the-Middle (MitM) attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing MitM attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

2. Increase the HSTS cache validity period in stages. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

3. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

4. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See 'ICT security guidelines for web applications' from NCSC-NL, guideline U/WA.05 (in Dutch).

We check if your web server only supports secure TLS versions (i.e. with a security level of 'Good' or 'Sufficient').

A web server may support more than one TLS version.

Please note that modern browsers no longer support TLS 1.0/1.1 and SSL. As a result, websites that do not support TLS 1.2 and/or 1.3 are unreachable for almost everyone.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.3.1.

Security level of TLS versions

• Good: TLS 1.3
• Sufficient: TLS 1.2
• Insufficient: TLS 1.0/1.1, SSL 1.0/2.0/3.0

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.4.1.

Security level of TLS compression

• Good: N/A (TLS 1.3)
• Good: No TLS compression (TLS 1.2)
• Insufficient: TLS compression (TLS 1.2)

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.4.2.

Security level of insecure renegotiation

• Good: N/A (TLS 1.3)
• Good: No insecure renegotiation (TLS 1.2)
• Insufficient: Insecure renegotiation (TLS 1.2)

We check whether a client (usually a web browser) can initiate a renegotiation with your web server and, if so, whether the number of allowed renegotiations is sufficiently limited.

Allowing clients to initiate renegotiation is generally not necessary. Client-initiated renegotiation opens a web server to DoS attacks inside a TLS connection. Therefore it is important either not to allow renegotiations or to strictly limit their number. We consider more than 10 allowed renegotiations as insufficient.

An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections. However, these are easier to detect and defend against using standard mitigations.

Note that client-initiated renegotiation could impact availability, but not confidentiality.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.4.2.

Requirement level: Recommended

Security level of client-initiated renegotiation

• Good: N/A (TLS 1.3)
• Good: No renegotiation (TLS 1.2)
• Sufficient: Limited renegotiation (TLS 1.2)
• Phase out: Unlimited renegotiation (TLS 1.2)

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT for non-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable. For web servers that support TLS 1.3, the index / page of the website is fetched using TLS 1.3 and the amount of early data support indicated by the server is checked. When more than zero, a second connection is made re-using the TLS session details of the first connection but sending the HTTP request before the TLS handshake (i.e. no round trips (0-RTT) needed before application data to the server). If the TLS handshake is completed and the web server responds with any non-HTTP 425 Too Early response, then the web server is considered to support 0-RTT.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.4.4.

Security level of 0-RTT

• Good: No 0-RTT (TLS 1.3)
• Good: N/A (TLS 1.2)
• Insufficient: Using 0-RTT (TLS 1.3)

We check if your web server supports the TLS Certificate Status extension (also known as OCSP stapling), in case the certificate on your webserver has a pointer to an OCSP server.

Note that we do not use the OCSP data to evaluate the validity of the certificate. Furthermore, note that OCSP has been deprecated by several certificate authorities. In case your website certificate does not have a pointer to an OCSP server, this subtest will pass.

The web browser can verify the validity of the certificate presented by the web server by contacting the certificate authority using the OCSP protocol. OCSP provides a certificate authority with information on browsers communicating to the web server. This may be a privacy risk. A web server can also provide OCSP data to a web browser directly through OCSP stapling. This solves this privacy risk, does not require connectivity between web browser and certificate authority, and is faster.

When connecting to your web server we use the TLS Certificate Status extension to request OCSP data be included in the server response. If your web server includes OCSP data in the response we then verify that the OCSP data is valid i.e. correctly signed by a known certificate authority.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.4.5.

Requirement level: Optional

Security level of OCSP stapling

• Good: Certificate without OCSP pointer
• Good: Certificate with OCSP pointer, stapling enabled, and valid OCSP data
• Insufficient: Certificate with OCSP pointer, stapling enabled, but no valid OCSP data
• Informational: Certificate with OCSP pointer, but no stapling enabled

We check if your web server supports Extended Master Secret.

Extended Master Secret (EMS), that is specified in RFC 7627, is an extension for TLS 1.2 that prevents Triple Handshakes machine-in-the-middle attacks.

Increasingly, TLS libraries are enforcing EMS by default, also because security regulations such as FIPS require it. If your server does not support EMS, clients that enforce EMS will be unable to establish a TLS 1.2 connection with your server.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 4.1.

We check if we are able to build a valid chain of trust for your website certificate.

For a valid chain of trust, your certificate must be signed by a publicly trusted certificate authority, and your web server must present all necessary intermediate certificates. The certificates must not have expired.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 4.4.

We check if your website certificate is signed (by a certificate authority) with a secure signing algorithm, while making use of a secure hash function.

For details on the relevant certificate field name see paragraph "4.1.1.2. signatureAlgorithm" of RFC 5280.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.3.5.

Security level of signing algorithms

• Sufficient: ECDSA, RSA, EdDSA
• Insufficient: DSS, EXPORT-*, PSK, Anon, NULL, KRB5

Security level of hash functions

• Good: SHA-256, SHA-384, SHA-512
• Phase out: SHA-224
• Insufficient: SHA-1, MD5

We check if the domain name of your website matches the domain name on the certificate.

It could be useful to include more than one domain (e.g. the domain with and without www) as Subject Alternative Name on the certificate.

See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 4.4.

We check if the name servers of your website domain contain one or more CAA records, that are syntactically valid and sufficiently protective.

Certification Authority Authorisation (CAA) allows you as a domain name holder to specify one or more certificate authorities authorised to issue certificates for your domain name. A certificate authority must not issue a certificate unless the CA determines that the certificate request is consistent with the applicable CAA records.

Note that CAA records are located during validation by walking up the DNS hierarchy until one or more records are found. For example, if no CAA records are found on sub.example.org, example.org will be queried. The domain were the applicable CAA records are found is shown in the table with technical details below.

The verdict is good if one or more CAA records were found that all have correct syntax, and at least one of these CAA records has the issue tag with a valid value. Otherwise, the test will result in a fail. It is not checked whether the certificate authority of the current certificate matches one or more of the issue and issuewild values, i.e., whether the current certificate could be reissued at this time.

If your are using the Automatic Certificate Management Environment (ACME) standard and your certificate authority supports it, we recommend you to use the parameters validationmethods and accounturi to further restrict isssuance by the authorised certificate authority. Furthermore, it is recommended to add issuewild, issuemail and issuevmc with an empty ; if you do not use wildcard, S/MIME and/or BIMI certificates respectively. This is especially important for issuemail and issuevmc, because in their absence there is no fallback to issue and thus any certificate authority can still issue S/MIME and/or BIMI certificates for your domain.

We expect URLs in iodef to be secure (i.e. use HTTPS scheme). Furthermore, to prevent suppression or spoofing of CAA records we strongly recommend you to use DNSSEC, although this CAA test does not specifically test for DNSSEC.

Requirement level: Recommended

We check if your web server provides an HTTP header for X-Frame-Options that has a sufficiently secure policy. With this HTTP header you let web browsers know whether you want to allow your website to be framed or not. Prevention of framing defends visitors against attacks like clickjacking. We consider the following values to be sufficiently secure:

• DENY (framing not allowed); or
• SAMEORIGIN (only framing by your own website allowed).

Although the value ALLOW-FROM (only allow specific websites to frame your website) is part of the X-Frame-Options specification (RFC 7034), it is not supported by most modern web browsers. Therefore we do not consider this value as sufficiently secure.

Note that Content-Security-Policy (CSP) offers similar protection through frame-ancestors and besides much more for visitors with modern web browsers. However X-Frame-Options could still protect visitors of older web browsers that do not support CSP. Furthermore X-Frame-Options could offer valuable protection for all visitors when CSP is not (properly) configured for the website concerned.

Also see 'Web application guidelines from NCSC-NL', guideline U/PW.03 (in Dutch).

Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.

Requirement level: Optional

We check if your web server provides an HTTP header for X-Content-Type-Options. With this HTTP header you let web browsers know that they must not do 'MIME type sniffing' and always follow the Content-Type as declared by your web server. The only valid value for this HTTP header is nosniff. When enabled, a browser will block requests for style and script when they do not have a corresponding Content-Type (i.e. text/css or a 'JavaScript MIME type' like application/javascript).

'MIME type sniffing' is a technique where the browser scans the content of a file to detect the format of a file regardless of the declared Content-Type by the web server. This technique is vulnerable to the so-called 'MIME confusion attack' in which the attacker manipulates the content of a file in a way that it is treated by the browser as a different Content-Type, like an executable.

Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended

We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your domain.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server's IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

We check if the validation status for all IP addresses of the name servers of your domain is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server's IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

• the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
• the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server's IP addresses to fix the route configuration error.

We check if an RPKI Route Origin Authorisation (ROA) has been published for all IP addresses of your web server.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server's IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorisation (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

We check if the validation status for all IP addresses of your web server is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server's IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

• the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
• the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server's IP addresses to fix the route configuration error.