Your Website Has HTTPS. What Does That Actually Protect?

“The site is secure. It has HTTPS.” That answer is reassuring until the next question: secure against what?

A working certificate is essential. But a certificate renewal notice and a website maintenance report describe different responsibilities. Confusing them can leave important work without an owner.

What does HTTPS actually do?

HTTPS uses Transport Layer Security, or TLS, to protect the exchange between a browser and a website. It helps prevent someone along the network path from reading or altering that exchange. Certificate validation helps the browser authenticate the connection to the requested hostname. MDN explains the underlying protections.

That is valuable. It is also narrower than “this business is trustworthy” or “this application has no vulnerabilities.” A misleading page can arrive over an encrypted connection.

Start with a connection check

For a website you operate, review the following:

• Certificate: Is it valid for the hostname visitors use? Who receives expiry or renewal-failure alerts?
• Redirects: Does the HTTP address reach the intended HTTPS address?
• Page resources: Are images, scripts, and styles also served over HTTPS?
• Important journeys: Do login, contact, checkout, and download pages work without browser warnings?

Test more than the homepage. A redesigned front page can coexist with an older form or forgotten subdomain. Record the exact address you checked and the date, so a later result can be compared with it.

Then ask who maintains the website

Here is a practical owner’s exercise: name the person responsible for each of four jobs—software updates, administrator access, backups, and incident handling. A hosting invoice may cover some of them, but the invoice alone does not tell you which.

Consider a hypothetical small company whose certificate renews automatically while an old administrator account remains active after a contractor leaves. The browser can show a protected connection even though the access problem remains. The corrective action is an account review, not another certificate.

Security headers need context

Headers can tell browsers how to handle a site. HSTS, for example, instructs supporting browsers to use HTTPS for a specified period. Its subdomain and preload options have operational consequences. Review MDN’s HSTS documentation before applying a policy broadly.

Do not paste an unfamiliar collection of headers into production just to improve a score. Ask what each setting does, which pages it affects, how it will be tested, and how you would undo the change. A good review produces a usable configuration and a working site.

Turn findings into a short work list

Use four columns in your maintenance notes: finding, affected address, responsible person, and next check. “Certificate renewal has no monitored alert address” is actionable. “Website security is weak” is not specific enough to assign.

The YNIA tools directory lists HTTPS, redirect, cookie, and security-header checks. These inspect public-facing configuration; they do not replace an application review or prove that the site has never been compromised. Confirm significant findings before changing anything.

Finish by checking one recovery question: if an update breaks the site tomorrow, who can restore a known working copy? That conversation will tell you something a padlock cannot.