Free tool, no account required

Free Website Security Checker: TLS, Headers and Open Ports

The Website Security Checker is a limited external check of a public site. It reads the TLS certificate, six security response headers, visible server identifiers and the reachability of seven common TCP ports.

Also known as: SSL checker, security headers test
Evidence shown with sourceNo account requiredNo invented metrics

Run a real check above

Submit a public URL, domain, or keyword. Novaverb will show only the evidence this tool can actually retrieve or measure.

Definition

What is a website security checker?

A website security checker is a tool that reads the security signals a public site shows to any outside visitor. The Novaverb Website Security Checker performs one live TLS handshake, reads one HTTPS response and attempts seven selected TCP ports for the exact hostname submitted, then reports each observation as point-in-time evidence.

Scope

What does the website security checker check?

The website security checker checks the TLS certificate, six response headers, visible server identifiers and seven TCP ports. For the certificate it records issuer, negotiated TLS version, cipher suite and lifetime left. The headers are HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy. The ports are 21, 22, 23, 25, 3306, 5432 and 6379.

Who it is for

Who is the website security checker for?

The website security checker is for people who own a public site or are authorized to test it. A developer confirms that headers added at the server or edge are actually served. An agency reviews a new client's hostname before work starts. A site owner checks how many days a certificate has left.

Why it matters

Why use a website security checker?

A website security check catches configuration gaps that are visible from outside before they cost visitors. An expired, mismatched or untrusted certificate can block users. A database, Redis or Telnet port that answers on a public host needs an ownership review. A header that is not declared leaves a browser policy unset.

Method

How does the website security checker work?

The website security checker works in a fixed order. The hostname is resolved to a public address, and private or reserved targets are rejected. A live TLS connection verifies the hostname and certificate chain. One request to the HTTPS homepage records the selected headers and server identifiers. TCP connections are then attempted to seven ports.

  1. We open a live TLS handshake and read the certificate, negotiated protocol version and cipher.
  2. We inspect the response headers for the six OWASP baseline security headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy).
  3. We note the disclosed Server banner and probe a small set of common TCP ports for exposure.
  4. We report each signal as present / missing / weak - never as a claim that the site is 'secure', because an external probe cannot prove that.
Input

What do you enter into the website security checker?

Enter a public domain or any URL on it into the website security checker. The exact hostname is tested, including www when supplied, because different hostnames can terminate at different edges. Internal hosts, private addresses and reserved targets are refused. A staging hostname says nothing about production unless both names reach the same deployed system.

Use it like this
yourdomain.comAny public site you own or are authorized to test. http or https, with or without www, a bare domain or a full path - we normalize it for you.
https://www.yourdomain.comThe probe reads only what any browser can see - no login, no exploitation.
Avoid this
Expecting a penetration testThis is a non-intrusive external probe, not an exploit scan - it cannot prove a site is secure or compromised.
admin.internal.corpInternal or private hosts are blocked. Only publicly resolvable, authorized sites are checked.
Result

What does the website security checker report contain?

The website security checker report contains summary tiles and detail panels. The tiles show certificate status, headers declared out of the total, selected ports answering and whether server identifiers were disclosed. The panels give TLS connection facts, HTTPS response exposure, a table of each header with its returned value and purpose, and the answering TCP services.

Reading it

How do you read a website security check result?

Read a website security check result as a configuration snapshot, not a verdict that the site is safe. Start with a failed certificate. Next review any answering port flagged for high-priority review, which covers Telnet, MySQL, PostgreSQL and Redis. Then look at headers marked not observed. Declared means returned, not correctly configured.

What does this Website Security Checker test?

Novaverb performs a limited external check of a public website: it verifies the TLS certificate presented on port 443, reads selected HTTPS response headers, notes visible server identifiers, and attempts TCP connections to seven commonly reviewed service ports. The output is point-in-time evidence - not a full vulnerability scan, malware scan or penetration test.

How the free website security check works

1

Validate the target

The checker accepts only a publicly routable hostname and rejects private or reserved network targets.

2

Verify TLS

It opens a live TLS connection, verifies the hostname and certificate chain, then records the negotiated version and cipher.

3

Read one response

It requests the HTTPS homepage and records six selected policy headers plus visible server identifiers.

4

Attempt seven ports

It attempts TCP connections to 21, 22, 23, 25, 3306, 5432 and 6379. A response means reachable, not vulnerable.

Measured evidence versus security claims

What this check can observe

  • Whether a browser-trusted TLS certificate can be verified for the hostname
  • The negotiated TLS version and cipher suite for one connection
  • Whether six selected HTTP security headers were declared on one response
  • Whether seven selected TCP ports accepted a connection from the Novaverb probe
  • Server and X-Powered-By identifiers returned in response headers

What this check cannot prove

  • That the website is safe, hacked, malware-free or compliant
  • That a declared CSP, HSTS or Permissions-Policy is complete and effective
  • That every port is closed or that an answering service is exploitable
  • The security of source code, plugins, packages, login flows, APIs or cloud accounts
  • WAF effectiveness, internal network controls or attacks from other locations

How to prioritize the findings

  1. Fix certificate verification failures first. An expired, mismatched or untrusted certificate can block users and removes authenticated HTTPS protection.
  2. Review reachable database, Redis and Telnet services. Confirm ownership, business need, authentication, patch state and network allowlists. Do not infer a breach from reachability alone.
  3. Validate policy values, not just header names. A weak CSP or max-age=0 HSTS declaration may provide little or no protection even though the header exists.
  4. Reduce unnecessary implementation disclosure. Hide detailed version banners where practical, but patching and secure configuration remain the real controls.
  5. Run authenticated and application-layer testing separately. Use code review, dependency scanning, access-control tests and an authorized penetration test for deeper assurance.

Standards behind these checks

The page distinguishes observation from interpretation and links to the primary specifications used to explain each signal.

Website Security Checker questions

Does a high result mean my website is secure?

No. This page intentionally does not create a general security score. It reports a small set of externally observable configuration signals.

Is an open port automatically a vulnerability?

No. A successful TCP connection only shows that something answered from this probe location. Risk depends on the service, authentication, patching, exposure policy and configuration.

Does a present security header mean it works?

No. Presence is only the first check. The value may be syntactically invalid, overly permissive, scoped incorrectly or incompatible with the application.

Why can a header result be unavailable instead of missing?

If the HTTPS request times out or cannot retrieve response headers, there is no evidence to call a header missing. The checker keeps that distinction explicit.

Does this tool test XSS, SQL injection or malware?

No. It sends no attack payloads and does not inspect application code, databases, files, accounts or dependencies.

Why is HTTPS not a complete security guarantee?

TLS protects authentication, confidentiality and integrity in transit. It does not fix vulnerable code, weak passwords, stolen accounts or unsafe server configuration.

This is a non-intrusive external probe of TLS, response headers and a few common ports - not a vulnerability scan or penetration test, and it cannot prove a site is secure.

Source

Where does the website security checker get its data?

The website security checker gets its data from the site itself during the check: one live TLS handshake on port 443, one HTTPS response from the homepage and seven TCP connection attempts sent by the Novaverb probe. The header observations come from that single response, so the result is point-in-time evidence.

Limits

What does the website security checker not tell you?

The website security checker does not tell you whether a site is secure or compromised. The check is a limited, non-intrusive external probe, not a vulnerability scan or penetration test. No attack payloads are sent, and application code, plugins, login flows, databases and accounts are not inspected. Ports outside the seven attempted stay unknown.

Evidence

What does a website security check result prove?

A website security check result proves what one probe observed: whether a browser-trusted certificate could be verified for the hostname, which TLS version and cipher one connection negotiated, which of six headers one response declared and which of seven ports accepted a connection. A declared policy is not proven complete or effective.

1. Source

One live TLS handshake, HTTPS response, and seven selected TCP-port probes. The result identifies where its evidence came from.

2. Boundary

This is a limited, non-intrusive external probe - not a vulnerability scan or penetration test. It cannot prove that a website is secure or compromised.

3. Next action

Use the finding to verify a problem, then connect a workspace when you need history, monitoring, or site-wide analysis.

Standards

Which standards does the website security checker apply?

The website security checker applies published references for each signal. RFC 8446 defines TLS 1.3 and frames the negotiated version and certificate reading. RFC 6797 defines HSTS. W3C CSP Level 3 defines Content-Security-Policy. The OWASP Secure Headers project identifies the baseline of six headers. Observed presence is kept apart from full configuration validation.

IETFRFC 8446
TLS 1.3

Reads the negotiated TLS version and certificate from a live handshake.

Read the specification
IETFRFC 6797
HTTP Strict Transport Security (HSTS)

Checks whether a Strict-Transport-Security header is present in the captured response.

Read the specification
W3CCSP Level 3
Content Security Policy

Checks whether a Content-Security-Policy header is present; it does not validate the full policy.

Read the specification
OWASPSecure Headers
OWASP Secure Headers Project

Compares your response headers against the OWASP baseline of six security headers.

Read the specification
We list a standard only where this tool genuinely reads or measures against it. Where a signal is outside a live check, the result says so instead of implying coverage.
Verification

How can you verify a website security check result yourself?

Verify a website security check result by repeating each observation from your own browser. View the certificate details for the site to confirm the issuer and expiry date. Load the homepage with the developer tools open and read the response headers in the network panel. Confirm with the server administrator which services are intentionally public.

Example

What does a typical website security check finding look like?

A typical website security check finding is a verified certificate beside an incomplete header set. The TLS tile reads verified, the header table shows Strict-Transport-Security and X-Content-Type-Options as declared, and Content-Security-Policy and Permissions-Policy as not observed. None of the seven selected ports answered, and the Server header names the web server software.

Cost

Is the website security checker free?

The website security checker is free and runs without an account. Enter a hostname and the live observation appears on the page. An account is needed only for what continues after the check: fixing the missing security headers, scanning again to prove they are live and monitoring TLS and headers over time.

In a workspace

What does a Novaverb workspace add to the website security checker?

A Novaverb workspace adds history and site-wide coverage to the website security checker. Site Trust & Security is the product that continues this job: a bounded scorecard for captured site trust signals, headers and supported external probes. Evidence is saved, changes are monitored over time and a finding can become a task that is rechecked.

Site Trust & Security (site trust and security)

When to go further

When is a free website security check not enough?

A free website security check is not enough when one hostname and one response cannot answer the question. The header reading comes from the homepage only, so other pages need a crawl of the whole site. A certificate nearing expiry needs recurring monitoring. Application-layer assurance needs code review, dependency scanning and an authorized penetration test.

Next step

What should you do after running the website security checker?

After running the website security checker, fix findings in priority order. Repair any certificate verification failure first. Review reachable database, Redis and Telnet services for ownership, authentication and network allowlists. Add missing headers at the web server or CDN edge, starting with HSTS, X-Content-Type-Options and Referrer-Policy. Validate the policy values, then check again.

Related tools

The website security checker pairs with free tools that look at neighboring evidence. The Website Safety Checker looks the URL up on Safe Browsing threat lists for malware and phishing. The WordPress Security Configuration Checker observes public WordPress configuration areas, XML-RPC and the login path among them. The HTTP/3 Test attempts a real QUIC connection.

Website SEO CheckerHomepage status, indexability, title, headings and links from one live scan
Keyword Research ToolFree keyword research tool: monthly searches, cost per click, ad …
SERP CheckerFree SERP checker: the organic results for a keyword in …
WordPress Security Configuration CheckerFree WordPress security checker: eight public configuration areas on a …
Server Response Time CheckerFree server response time checker: one live request from Germany, …
Backlink CheckerFree backlink checker: see the referring domains, link totals, follow …
Robots.txt CheckerFree robots.txt tester: fetch a site's live robots.txt and see …
Sitemap CheckerFree sitemap checker: find a site's XML sitemaps from robots.txt …
Meta Tag CheckerFree meta tag checker: a page's live title, meta description, …
HTTP Status & Redirect CheckerFree redirect checker: trace every hop of a URL's redirect …
Website MonitorFree website status checker: one live request to your address …
HTTP/2 TestFree HTTP/2 test: opens one live TLS connection to a …
HTTP/3 TestFree HTTP/3 test: attempts a real QUIC connection to a …
Website Performance TestFree website performance test: time one request to your URL …
GEO CheckerFree GEO checker: retrieve, quote, cite and graph signals from …
Core Web Vitals CheckerFree Core Web Vitals checker: real-user LCP, INP and CLS …
PageSpeed CheckerFree PageSpeed checker: a Lighthouse lab audit of a public …
Website Safety CheckerFree website safety checker: see whether a URL is listed …
Knowledge Graph CheckerFree Knowledge Graph checker: look up a brand or name …
Keyword Gap CheckerFree keyword gap analysis: keywords a competitor ranks for and …
Competitor Top PagesFree competitor top pages tool: a domain's leading pages by …
Questions

What do people ask about the website security checker?

The website security checker FAQ answers what the tool actually checks, whether the probe equals a penetration test or vulnerability scan, how to fix missing headers and what HSTS is. Further questions cover which headers every site should send, why a detailed Server header matters, what a good open-ports result is and whether clean means secure.

What does the Novaverb Website Security Checker actually check?

It runs a limited external probe of a public site: the TLS certificate, six security response headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy), the disclosed Server header, and seven common TCP ports.

Is this the same as a penetration test or vulnerability scan?

No. It is a non-intrusive external probe that reads publicly visible signals only. It does not exploit anything, log in, or scan for CVEs, and it cannot prove a site is secure or that it is compromised.

How do I fix missing security headers flagged by the checker?

Add the missing headers at your web server or CDN edge. Start with HSTS (Strict-Transport-Security), X-Content-Type-Options: nosniff, and a Referrer-Policy, then build a Content-Security-Policy, which is the hardest to configure safely.

What is HSTS and why does it matter?

HSTS (HTTP Strict-Transport-Security) is a response header telling browsers to always use HTTPS for your domain, preventing protocol-downgrade and cookie-hijacking attacks. A good baseline is max-age of at least 31536000 seconds (one year).

Which security response headers should every site send?

The OWASP Secure Headers baseline includes Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy. The checker reports which of these six are present, missing, or misconfigured.

Why does exposing my Server header matter?

A detailed Server header (naming software and version) hands attackers a version fingerprint to match against known exploits. Suppressing or genericising it via server config removes an easy reconnaissance signal, though it is hardening, not a real fix.

What is the difference between a TLS certificate check and this security scan?

A certificate check alone confirms encryption is valid and unexpired. This scan reads the certificate too, but adds response headers, the Server banner, and open ports, giving a broader external hardening snapshot rather than a single trust signal.

What is a good result for the open-ports part of the check?

Ideally only the ports you intend to serve publicly (typically 443, and 80 for redirects) respond. Exposed database, remote-desktop, or admin ports on a public host are worth reviewing and firewalling off.

Does a clean result here mean my website is secure?

No. A clean external probe means these specific public signals look healthy. It says nothing about application logic, authentication, unpatched software, or server-side vulnerabilities, so treat it as one input, not a certificate of security.

How does website security affect SEO?

Valid HTTPS protects data in transit and avoids browser security warnings. That supports visitor trust and reliable delivery, while this limited probe makes no claim about rankings or the site's full security posture.

Check → understand → fix

Turn this check into a verified fix

Every Novaverb free tool is one funnel: run the check, understand the evidence, then fix it and prove it is resolved with a fresh re-check - no invented pass states.