Practical Security Guides For Your Team

Your server is using a self-signed security certificate — one that you (or your server) created yourself, rather than one issued by a trusted authority. Browsers treat this the same way they'd treat a badge someone printed at home: it might look official, but there's no independent body vouching for it. Visitors to your site will see a security warning, and some browsers may block access entirely.

Your website can be visited over plain HTTP (unencrypted), and it doesn't automatically send visitors to the secure HTTPS version. Any user who lands on an HTTP link — from an old email, a bookmark, or a mistyped URL — will have their connection left unprotected. Think of it like a shop that has a secure back entrance but leaves the front door unlocked with no sign pointing visitors to the right way in.

Your website already uses a secure connection (HTTPS), which is great. But there's a setting that tells browsers how long to remember to always use that secure connection — and yours is set too low. Think of it like a reminder that expires too quickly: if a user's browser forgets before their next visit, there's a brief window where they could be exposed to a connection that isn't fully protected.

Your website is missing a small but important instruction it should send to browsers — one that tells them to always use a secure, encrypted connection. Without it, browsers may occasionally connect over an unencrypted channel, and there is no browser-level safeguard to prevent that from happening. Think of it like a lock on your front door: your HTTPS certificate is the lock, but this header is the sign that tells visitors to always use the locked entrance.