Grading Security Headers Isn't the Full Picture

Grading security headers is not the complete picture when evaluating website security. While security-header grading can be useful in highlighting tradeoffs, it is not sufficient on its own. Content Security Policy (CSP), for example, requires context because a stricter policy may be technically correct but still break the product if implemented blindly.

A report-only CSP scores the same as a fully enforced one, which is a significant oversight. This mistake can lead to a false sense of security when a team has a report-only CSP in place, just as a team that has shipped a broken policy and never noticed. The grading process misses a crucial aspect: the TLS layer underneath the headers.

Headers provide insight into the intent, but TLS reveals the reality. A perfect header score does not guarantee a secure HTTPS connection. Strict-Transport-Security (HSTS) instructs browsers to only load the site over HTTPS, but it does not address the validity of the certificate serving that HTTPS connection, the time remaining until its expiration, the TLS version negotiated, or the issuing authority.

A site's security audit can score well on headers but still operate on an expiring certificate. To gain a more accurate understanding of a site's security, it is necessary to perform a live handshake using tools like ssl and socket, and check the certificate information. This process involves blocking I/O, so it should be implemented in an asynchronous service.

It must also fail softly, handling self-signed certificates, non-TLS ports, and slow/unreachable hosts gracefully. Additionally, the TLS inspection should be an optional feature, not a default, to prevent unnecessary latency for users who do not require it. The author implemented both fixes - Report-Only-aware header context and opt-in TLS inspection - separately in their API to address these issues.