How to Check Your Website Is Secure: A Complete Guide

What "secure" actually means (and what most site owners get wrong)#

Ask most site owners whether their website is secure and you will hear the same answer: "Yes, we have SSL." That answer confuses one layer of security with the whole picture. An SSL certificate (more accurately, a TLS certificate) encrypts the connection between your server and the visitor's browser. That is important. But it says nothing about what happens once the data arrives.

A site with a valid certificate can still be vulnerable to clickjacking, where an attacker loads your page inside an invisible frame and tricks visitors into clicking buttons they cannot see. It can still leak session cookies over unencrypted connections. It can still allow injected scripts to run because no Content Security Policy was ever set. It can still have its domain spoofed in phishing emails because no SPF or DMARC records exist.

Real website security is a stack of protections, each covering a different attack surface. HTTPS is the foundation, but it is only the first layer. Beyond configuration, runtime defenses like web application firewalls (WAFs), rate limiting, bot protection, and DDoS mitigation add another layer by filtering malicious traffic before it reaches your application. Those are important, but they are deployment decisions rather than things you can verify in a browser. The sections below focus on the configuration layers you can check yourself in under an hour.

Check your HTTPS and TLS configuration#

Having a certificate is the starting point, not the finish line. The certificate itself can be misconfigured in ways that weaken or break the encryption it provides. Here is what to verify.

Certificate validity. Expired certificates trigger browser warnings that scare visitors away. Most certificate authorities offer automated renewal, but it is worth confirming that renewal is actually running. A certificate that expired overnight can go unnoticed until a customer reports it.

TLS version. TLS 1.0 and 1.1 are deprecated and considered insecure. Modern browsers already refuse to connect over these versions. Your server should support TLS 1.2 at minimum, with TLS 1.3 preferred. TLS 1.3 is faster (fewer round trips during the handshake) and removes several cipher suites that were vulnerable in older versions.

Cipher suites. Even on TLS 1.2, weak ciphers like RC4, 3DES, and CBC mode ciphers with TLS 1.0 are vulnerable to known attacks. Your server configuration should explicitly disable these and prefer AEAD ciphers like AES-GCM and ChaCha20-Poly1305.

Certificate chain. Your server needs to send the full certificate chain, including intermediate certificates. If an intermediate certificate is missing, some browsers and devices will fail to validate the connection, even though the certificate itself is valid. This is one of the most common TLS misconfigurations.

How to check: Open your site in Chrome, click the padlock icon, then go to "Connection is secure" and "Certificate is valid" to inspect the certificate details. For a deeper check, open DevTools (F12), go to the Security tab, and review the TLS version and cipher suite in use. You can also run your domain through a free TLS handshake checker to see your certificate chain, protocol version, and cipher negotiation in one view. For a full breakdown of how the connection is negotiated, see the TLS handshake guide.

Check your security headers#

Security headers are instructions your server sends alongside every page response, telling the browser how to handle the content. Without them, browsers fall back to decades-old defaults that leave common attack vectors wide open. These are the five headers that matter most.

• Content-Security-Policy Controls which scripts, styles, images, and other resources are allowed to load on your page. Without it, any injected script runs freely, making cross-site scripting (XSS) trivial to exploit.
• Strict-Transport-Security Tells the browser to only connect to your site over HTTPS, even if someone types an HTTP URL or clicks an old bookmark. Without it, the first request can be intercepted and redirected by an attacker on the same network.
• X-Content-Type-Options Stops browsers from guessing what type of file a response contains, a behavior called MIME sniffing. Without it, an uploaded text file could be interpreted as executable JavaScript.
• X-Frame-Options Prevents your page from being loaded inside an iframe on another website. Without it, an attacker can overlay your page with invisible elements and trick visitors into clicking buttons they cannot see. This is called clickjacking.
• Referrer-Policy Controls how much of the current page URL is shared with other sites when a visitor clicks a link or a resource loads. Without it, full URLs, potentially containing session tokens or sensitive paths, are sent to every external resource.

How to check: Open DevTools, go to the Network tab, click on the initial page request, and scroll to the Response Headers section. Each of these headers should be present. If you want to check all five at once without opening DevTools, a free security scan will show which headers are present, which are missing, and whether the ones you have are configured correctly. For a detailed walkthrough of what to look for in each header's value, see the security headers checking guide. For ready-to-use configurations, see the security headers cheat sheet.

Check your cookie security#

Cookies store session identifiers, authentication tokens, and user preferences. If they are not configured with the right flags, they become one of the easiest things for an attacker to steal. Three attributes matter most.

• HttpOnly Prevents JavaScript from reading the cookie. This is the primary defense against session theft through cross-site scripting. If an attacker manages to inject a script into your page, the HttpOnly flag ensures the script cannot access the session cookie and send it to an external server.
• Secure Ensures the cookie is only sent over HTTPS connections. Without it, a cookie set on your HTTPS site could be transmitted in plain text if the browser makes an HTTP request, for example through a redirect or a mixed content resource.
• SameSite Controls whether the cookie is sent along with cross-site requests. Setting this to Lax or Strict prevents the browser from including your session cookie in requests triggered by other websites, which is the foundation of cross-site request forgery (CSRF) protection.

How to check: Open DevTools, go to the Application tab (or Storage tab in Firefox), and click Cookies in the left sidebar. Each cookie is listed with its attributes. Look at the HttpOnly, Secure, and SameSite columns for your session cookies. For a deeper dive into cookie security and implementation examples, see the cookie security guide.

Check for mixed content and insecure resources#

Mixed content happens when an HTTPS page loads resources (images, scripts, stylesheets, fonts, or iframes) over plain HTTP. This undermines the encryption that HTTPS provides. Modern browsers handle mixed content in two ways: they block active mixed content (scripts and stylesheets) entirely, and they may allow passive mixed content (images) but show a degraded security indicator. Either way, mixed content signals to visitors that something is wrong.

The most common sources of mixed content are hardcoded http:// URLs in HTML templates, older CMS content that was created before the site migrated to HTTPS, third-party widgets and embeds that use HTTP endpoints, and CDN links that were configured without the HTTPS scheme.

How to check: Open DevTools and look at the Console tab. Browsers automatically log mixed content warnings with the exact URL of each insecure resource. For a more thorough scan, run a Lighthouse audit (DevTools > Lighthouse tab) which will flag every mixed content issue on the page. For a complete guide to finding and fixing mixed content issues, see the mixed content guide.

Check your DNS and email security#

This layer is the one most site owners skip entirely, because it lives in DNS rather than on the web server. But DNS records play a direct role in protecting your domain from abuse. Without them, anyone can send email that appears to come from your domain, and any certificate authority in the world can issue a certificate for your site.

• SPF (Sender Policy Framework). A DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks the SPF record to confirm the sending server is on the list. Without SPF, there is nothing stopping an attacker from sending phishing emails that pass basic validation.
• DKIM (DomainKeys Identified Mail). Adds a cryptographic signature to every outgoing email. The receiving server verifies the signature using a public key published in your DNS records. This proves the email was not modified in transit and that it was actually sent by a server that holds your private key.
• DMARC (Domain-based Message Authentication). Ties SPF and DKIM together with a policy that tells receiving servers what to do when an email fails both checks. You can instruct servers to quarantine or reject unauthenticated messages. DMARC also sends you reports showing who is sending email using your domain, both legitimately and fraudulently.
• CAA (Certificate Authority Authorization). A DNS record that specifies which certificate authorities are allowed to issue TLS certificates for your domain. Without a CAA record, any of the hundreds of public certificate authorities can issue a certificate for your site, which increases your exposure if one of those authorities is compromised.

How to check: Use a DNS lookup tool or run dig yourdomain.com TXT in a terminal to see your SPF and DMARC records. For DKIM, query the specific selector your email provider uses (e.g., dig selector._domainkey.yourdomain.com TXT). For CAA, run dig yourdomain.com CAA. For a complete walkthrough of each record type with examples, see the DNS security guide.

Your security audit checklist#

Here is everything from the sections above in one place. Use this as a quick reference when auditing a site or verifying changes after a deployment.

FAQ#