Website component
Domain security and configuration
DNSSEC
DNSSEC (Domain Name System Security Extensions) is a security extension to the DNS protocol designed to secure and authenticate DNS traffic. These extensions use asymmetric encryption to ensure the authenticity and integrity of the information exchanged between DNS servers and between these and the user's applications.
For a better understanding and correct implementation of DNSSEC you can check the DNS.PT reference document "DNSSEC Tutorial" (Only available in Portuguese).
Domain signed with DNSSEC
This test verifies if the domain name is signed with DNSSEC. Correct implementation of DNSSEC prevents manipulation of DNS responses, which could lead to unauthorized redirection of requests to a server controlled by a third party.
The domain name is not signed with DNSSEC.
DNSSEC signature validation
This test verifies if the domain name is signed with a valid DNSSEC signature and marked as "secure".
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
DANE
DANE (DNS-based Authentication of Named Entities) is a protocol that adds an additional layer of protection to the web service, as it allows you to securely specify information about the certificate that should be used to access your website.
The use of DANE depends on the DNSSEC implementation.
For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
TLSA record(s) of the web server(s)(Optional)
This test verifies the existence of a signed TLSA record for each of the web servers of your internet domain.
Since the correct DANE configuration depends on the DNSSEC implementation, this test will not be performed if the domain is not configured with DNSSEC.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Technical details:
The website does not have HTTPS
Validity of the TLSA record(s) of the web server(s)(Optional)
This test verifies if the DANE fingerprint published in the TLSA record(s) corresponds to the digital certificate(s) presented by the web server(s).
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Technical details:
The website does not have HTTPS
Connection security
HTTP/S
The HTTPS (Hypertext Transfer Protocol Secure) protocol represents an additional security layer to the HTTP protocol. The use of HTTPS in an internet domain aims to prevent the interception and/or manipulation by third parties of the communication between the browser and the server who hosts the website.
HTTPS Connection
This test verifies if the internet domain provides the HTTPS protocol for secure communication.
A secure communication channel (HTTPS) could not be established. The communication between the browser and the server hosting the internet domain can be compromised.
Technical details:
None: HTTPS Disabled
HTTPS Redirection
This test verifies if the Internet domain automatically forwards the communications from HTTP to HTTPS (in the same domain and through the code 301) or if it only supports the HTTPS protocol.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
HSTS
HSTS (HTTP Strict-Transport-Security) consists of a response header that allows an internet domain to communicate to the browser that it should only be accessed through the HTTPS protocol, thus avoiding the use of insecure and vulnerable channels, susceptible of interception and manipulation by third parties.
HSTS Support
This test checks if the internet domain supports HSTS.
To fully comply with this validation the HSTS header must be configured with a max-age value of more than 6 months. If the value of "max-age" is less than 6 months the result will be a partial compliance.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
HSTS Preload(Optional)
This test verifies if the internet domain is configured with HSTS preloading.
HSTS preloading allows you to place the domain in a built-in list of many internet browsers. If the domain is present in this list, whenever someone visits the website associated with it, it will automatically be forwarded to a secure channel (HTTPS). This feature is adopted by the most commonly used internet browsers such as Chrome, Firefox and Safari.
After you correctly implement the HSTS header, you can request to have your domain incorporated into this list in: https://hstspreload.org/.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
TLS
TLS (Transport Layer Security) is a cryptographic protocol designed to provide communications security. The use of secure versions of the TLS protocol, in combination with valid digital certificates, provides the visitors of an Internet domain a higher degree of security in the established connection.
Supported SSL/TLS Versions
This test checks if the Internet domain supports versions of the TLS protocol considered to be insecure.
Older versions of TLS (SSL v2.0, v3.0 and TLS v1.0) contain several well-known vulnerabilities, so they should not be adopted. The use of the TLS v1.1 protocol is considered a partial compliance with the test so the transition to TLS version 1.2 and / or higher (which represents a complete fulfillment of the verification) is advised.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Digital Certificate
A digital certificate (also known as SSL / TLS or public key certificate) consists of an electronic document, digitally signed by a certifying entity, that links the public key of the entity for which it is intended with their identification data and is used to guarantee the authenticity and integrity in electronic transactions.
Expiration Date
This test verifies if the digital certificate associated to the domain is not expired.
To fully comply with this validation, the digital certificate must present an expiration date of more than 30 days.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Certificate Chain
This test checks if the digital certificate associated with the domain is recognized by the most commonly used internet browsers and if it is correctly configured.
In order to fully comply with this validation, the certificate cannot be self-signed, must have a recognized "Root CA" and correctly present the intermediate certificates.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Security options
Security Headers
In addition to the HSTS security header there are still other HTTP headers that can contribute to improve the security of your internet domain name.
In addition to the HSTS security header there are still other HTTP headers that can contribute to improve the security of your internet domain name.
X-Content-Type-Options
This test verifies if the internet domain supports the "X-Content-Type-Options" security header with the "nosniff" option.
By using this security option, the browser will block any styles or scripts whenever they do not match with the content type. For example, a "style" in which the MIME type is not "text/css" will be blocked.
The internet domain does not support the "X-Content-Type-Options" security header.
Technical details:
X-Content-Type-Options header not found.
X-Frame-Options
This test verifies if the internet domain supports the "X-Frame-Options" security header. This header allows you to control whether the internet page associated with the domain can be included inside another web page (i.e. "framed"). This header can be implemented through three different options:
1. "deny", stating that the internet domain can never be "framed" within an internet page associated with another domain;
2. "sameorigin", stating that the internet domain can only be "framed" within an internet page of the domain itself;
3. "allow-from", stating that the internet domain can only be "framed" within an internet page belonging to the indicated domain(s).
The internet domain does not support the "X-Frame-Options" security header.
Technical details:
X-Frame-Options header not found.
Referrer-Policy
This test verifies if the internet domain supports the "Referrer-Policy" security header. This header is used to control what kind of information is sent through the "Referer" field.
This header can be implemented with the following options:
This header can be implemented with the following options:
1. "no-referrer", where all "Referer" information is omitted;
2. "no-referrer-when-downgrade", where "Referer" information is only sent when the same level of security is maintained (HTTP -> HTTP or HTTPS -> HTTPS);
3. "origin", where the information sent in "Referer" is only relative to the origin, for example, the document https://example.pt/page sends as "Referer" the value "https://example.pt/" ;
4. "origin-when-cross-origin", where the "Referer" information is sent in full when within the same domain, but only the origin when for other domains;
5. "same-origin", where "Referer" information is only sent within the same domain;
6. "strict-origin", where the "Referer" information is only relative to the origin and only sent when the same level of security is maintained;
7. "strict-origin-when-cross-origin", where the "Referer" information is sent in full when within the same domain, but only the origin when for other domains and maintaining the level of security;
8. "unsafe-url", where the "Referer" information is sent in full to any domain.
The internet domain does not support the "Referrer-Policy" security header.
Technical details:
Referrer-Policy header not found.
Content-Security-Policy(Optional)
This test verifies if the internet domain supports the "Content-Security-Policy" security header. This header allows you to define how and from which source the resources, such as javascripts and CSS, can be used by the web page. This security header can prevent cross-site scripting (XSS) attacks by blocking the script injection from unknown and unauthorized sources.
The internet domain does not support the "Content-Security-Policy" security header.
Technical details:
Content-Security-Policy header not found.
E-mail component
E-mail domain security and configuration
DNSSEC
DNSSEC (Domain Name System Security Extensions) is a security extension to the DNS protocol designed to secure and authenticate DNS traffic. These extensions use asymmetric encryption to ensure the authenticity and integrity of the information exchanged between DNS servers and between these and the user's applications.
DNSSEC (Domain Name System Security Extensions) is a security extension to the DNS protocol designed to secure and authenticate DNS traffic. These extensions use asymmetric encryption to ensure the authenticity and integrity of the information exchanged between DNS servers and between these and the user's applications.
For a better understanding and correct implementation of DNSSEC you can check the DNS.PT reference document "DNSSEC Tutorial" (Only available in Portuguese).
Email server(s) domain(s) signed with DNSSEC
This test verifies if the domain name(s) of the email exchange (MX) server(s) is(are) signed with DNSSEC. A correct implementation of DNSSEC prevents manipulation of DNS responses, which could lead to unauthorized redirection of requests to a server controlled by a third party.
At least one domain name of the email server(s) (MX) is not signed with DNSSEC.
Email server(s) domain(s) DNSSEC signature validity
This test verifies if the domain name(s) of the email exchange (MX) server(s) is(are) signed with a valid DNSSEC signature and marked as "secure".
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Authentication and Integrity
SPF
SPF (Sender Policy Framework) consists of a validation standard for the e-mail channel, based on the use of the Domain Name System (DNS) to publish the IP address(es) of the server(s) authorized to send e-mail on behalf of the domain. This is a method that allows the domain holder to specify which e-mail server (or servers) are allowed to send messages and enable the subsequent verification by the destination server.
For more information about SPF and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
SPF (Sender Policy Framework) consists of a validation standard for the e-mail channel, based on the use of the Domain Name System (DNS) to publish the IP address(es) of the server(s) authorized to send e-mail on behalf of the domain. This is a method that allows the domain holder to specify which e-mail server (or servers) are allowed to send messages and enable the subsequent verification by the destination server.
For more information about SPF and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
SPF Record
This test verifies if the e-mail domain has an SPF record.
The email domain has an SPF record configured.
Technical details:
SPF Record: v=spf1 include:spf.flockmail.com include:spf.mx.hostinger.com include:relay.mailchannels.net ~all
SPF Policy
This test verifies if the e-mail domain has a sufficiently restricted SPF policy.
To fully comply you have to implement a "hardfail" policy (-all). The implementation of a "softfail" policy (~ all) will result in a partial compliance of the requirements. The remaining SPF policy settings or an incorrect registry setting (for example, if there are more than ten DNS records to be resolved) result in non-compliance with the requirements of this test.
To fully comply you have to implement a "hardfail" policy (-all). The implementation of a "softfail" policy (~ all) will result in a partial compliance of the requirements. The remaining SPF policy settings or an incorrect registry setting (for example, if there are more than ten DNS records to be resolved) result in non-compliance with the requirements of this test.
The e-mail domain implements an SPF policy that was not considered secure enough.
DKIM
The use of DKIM (DomainKeys Identified Mail) aims to provide a method for validating a digital identity associated with a message (typically the sender's domain). The objective is the non-repudiation of the attribution of the message, achieved through a cryptographic signature attached to each sent message. DKIM uses public key cryptography, which means that there is a private key that only the message subscriber knows about, and a public key that everyone knows and can use to verify the message.
For more information about DKIM and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
For more information about DKIM and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
DKIM Record
This test verifies if the e-mail domain has a DKIM key/record. A recipient e-mail server can use this record to verify the authenticity and integrity of the incoming message. However it is not possible to check the validity of the DKIM key through this test since it would be necessary to know the domain DKIM selector (which is only present in the headers of the messages sent from this domain).
To fully comply with the requirements of this validation, and considering RFC2308, the domain name server is expected to respond "NOERROR" to the query "_domainkey.<domain_name>". If the answer is "NXDOMAIN" it is considered that you don't have DKIM enabled.
To fully comply with the requirements of this validation, and considering RFC2308, the domain name server is expected to respond "NOERROR" to the query "_domainkey.<domain_name>". If the answer is "NXDOMAIN" it is considered that you don't have DKIM enabled.
The e-mail domain does not have a DKIM record configured.
DMARC
DMARC (Domain-based Message Authentication, Reporting & Conformance) relies on the correct implementation of SPF and DKIM and unifies these two authentication mechanisms in a common framework that allows the owners of each domain to define how an e-mail message domain should be handled if an authorization test fails. Implementers of DMARC also benefit from the ability to gain greater visibility into legitimate and illegitimate emails sent through their domain name.
For more information about DMARC and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
DMARC Record
This test verifies if the e-mail domain has a DMARC record. The DMARC policy defines how a recipient e-mail server should act when it identifies a message that fails to comply with the SPF and/or DKIM policy set for the sending domain.
The e-mail domain does not have a DMARC record associated.
Technical details:
DMARC Record: Not Found
DMARC Policy
This test verifies if the e-mail domain has a sufficiently restricted DMARC policy. To fully comply with this test you have to implement DMARC with a policy of rejection or quarantine ("p = reject" or "p = quarantine"). When the non-action policy is applied ("p = none"), the test will result in a partial compliance.
Through the definition of the "rua=" and "ruf =" options, DMARC also enables the reception of aggregated reports of conformity ("rua") and forensic ("ruf") for a better vision and understanding of the degree of illegitimate use of the domain.
Through the definition of the "rua=" and "ruf =" options, DMARC also enables the reception of aggregated reports of conformity ("rua") and forensic ("ruf") for a better vision and understanding of the degree of illegitimate use of the domain.
This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.
Confidentiality
STARTTLS
For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
STARTTLS consists of an extension of the SMTP (Simple Mail Transfer) protocol that allows the use of Transport Layer Security (TLS) in order to ensure a secure and authenticated communication between two devices that wish to exchange an e-mail message . The use of STARTTLS is thus intended to prevent e-mail messages from being intercepted and / or manipulated on the way to their final destination.
For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
STARTTLS Support
This test verifies if the email server(s) associated with the domain supports a STARTTLS connection. If supported, the TLS protocol versions associated with that connection will be tested.
The e-mail server(s) associated to the domain do not support STARTTLS connections.
Supported SSL/TLS Versions
This test verifies if the e-mail server(s) associated to the domain support secure versions of the TLS protocol.
Older versions of TLS (SSL v2.0, v3.0 and TLS v1.0) contain several well-known vulnerabilities and should not be adopted. The use of the TLS v1.1 protocol is considered a partial compliance with the test, and the transition to TLS v1.2 and / or higher (which represents a complete fulfillment of the verification) is advised.
Older versions of TLS (SSL v2.0, v3.0 and TLS v1.0) contain several well-known vulnerabilities and should not be adopted. The use of the TLS v1.1 protocol is considered a partial compliance with the test, and the transition to TLS v1.2 and / or higher (which represents a complete fulfillment of the verification) is advised.