CDS · WEBSITE SECURITY EXPLAINER · 2026

The browser padlock matters. HTTPS helps protect data moving between a visitor’s browser and a website endpoint. But it does not prove that the entire website, its accounts, software or business processes are secure.

What HTTPS actually provides

These protections do not prove that application code, server configuration, administrator accounts, plugins or third-party scripts are safe.

What HTTPS does not automatically protect

• Vulnerable application code or insecure plugins.
• Weak passwords, compromised administrator accounts or poor access controls.
• Outdated software or unsafe server configuration.
• Malicious or compromised third-party scripts and dependencies.
• Incorrect cookie/session settings or unsuitable browser-security policies such as CSP.
• Every page and resource being forced to load securely.
• The website from ever being compromised, or the need for penetration testing.

Seven checks to make alongside HTTPS

1. Certificate and hostname

   Confirm the certificate is valid for the intended hostname, unexpired and normally validated by the browser. A certificate is a transport/authentication control—not a complete assessment.

2. HTTP-to-HTTPS enforcement

   Request the HTTP URL. Unless HTTP is intentionally required, the site should normally direct visitors to the intended HTTPS URL. Both protocols being accessible is a reason to review enforcement, not proof of compromise.

3. HSTS

   Check whether Strict-Transport-Security is intentionally configured for the deployment. HSTS can tell browsers to prefer HTTPS in future connections; it does not replace application security.

4. Mixed content

   Check whether an HTTPS page requests resources over insecure HTTP. HTTPS may be active while insecure resource references still need remediation.

5. Security headers

   Review CSP, X-Content-Type-Options, framing protections and Referrer-Policy where appropriate. These controls complement TLS.

6. Cookies and sessions

   For stateful applications, review appropriate Secure, HttpOnly and SameSite attributes. Correct settings depend on application design; a missing attribute alone does not prove session takeover.

7. Application and technology hygiene

   Identify observable CMS/framework/runtime components, then verify supported versions, patching, access controls and application-level security. HTTPS cannot repair insecure application logic or vulnerable components.

What our September 2026 review observed

In a CDS/AuthSetu review of 92 authorized public-facing targets, the normalized V5 dataset recorded HSTS on 50 targets (54.3%) and CSP on 45 (48.9%). These figures describe only that reviewed dataset; they are not representative estimates for all small-business websites.

Some reviewed cases had HTTPS active while other hardening questions remained, such as limited security headers, technology disclosure or HTTP/HTTPS handling. The evidence supported further configuration review—not a claim of compromise.

Common assumptions—and better interpretations

What a responsible conclusion sounds like

This is more useful than calling a site “unsafe” from the padlock alone because each point can be tested and verified.

When deeper testing is justified

If a website handles logins, payments, customer records, sensitive forms, internal workflows or privileged administration, treat passive HTTPS/header checks as a starting point. Based on risk and explicit authorization, authenticated assessment, vulnerability validation, secure-code review or penetration testing may be appropriate.

Related reading

• Website Security
• Website Security Audit
• MDN: HTTP overview
• OWASP Secure Headers Project

Scope and limitations: This educational article reflects defensive security methodology and a September 2026 authorized passive review. Automated observations can miss controls and do not establish compromise. Revalidate live configuration before target-specific claims. No unauthorized access or exploitation is implied.