Security checker
Check the security configuration your website exposes
Every site tells the outside world how it is configured before anyone types a password. The headers it sends, the TLS versions it agrees to, the attributes on its cookies, the records in its DNS zone and the software versions its server volunteers are all readable by anyone who asks politely. VeriFixScan asks politely, reads what comes back, and reports the configuration it found.
What can be read from outside, and what cannot
This is a configuration review, not a hunt for weaknesses. Everything reported here comes from ordinary requests any browser makes: response headers, the TLS handshake, Set-Cookie lines, public DNS answers and published files. Nothing is injected, nothing is fuzzed, no form is submitted and no login is attempted. That boundary is not a limitation of the scan budget — it is the deliberate shape of the tool.
Headers are the part browsers actually enforce
A Content-Security-Policy decides which resources a browser will load; framing rules decide whether your pages can be embedded in someone else's; a referrer policy decides how much of your URLs leaks to third parties. These are instructions the browser obeys on behalf of your visitors, which makes a missing one a real gap rather than a stylistic preference. Each is reported as sent or absent, with the value observed.
TLS is not a yes-or-no answer
A padlock in the address bar says a handshake succeeded. It says nothing about which protocol versions the server still accepts, whether the certificate covers both the apex and the www hostname, or whether Strict-Transport-Security is sent at all. Those are separate answers, and a site can pass the first while failing the others without anything visible going wrong.
Cookies carry the session, and the attributes decide who reads it
A cookie that looks session-related without HttpOnly is readable by any script on the page. One without Secure can travel over plain HTTP. One with SameSite absent or invalid behaves differently across browsers and versions. The attributes really present on the cookies your site sets are reported as observed, separately from the cookie inventory the scanner produces.
The zone, the mail and what the server volunteers
DNSSEC signing, the presence of a security contact policy, whether a domain with no mail service is still open to spoofing, and whether the server announces its exact software versions in a header — none of these are visible from a browser window, and all of them are visible from a request. They round out the picture the configuration presents to anyone looking.
The security configuration that gets read
Each of these is a real check, and each reports what the response actually contained rather than what was expected.
HSTS
Strict-Transport-Security is sent by the site.
Content-Security-Policy
A Content Security Policy restricts which resources the browser may load.
Clickjacking protection
Framing of the site is restricted (X-Frame-Options or CSP frame-ancestors).
TLS protocol versions
Which TLS versions the server accepts (TLS 1.0/1.1 deprecated, 1.2/1.3 expected).
Certificate hostname coverage
Both the apex and the www hostname complete an HTTPS handshake.
Secure attribute
Session-like cookies and SameSite=None cookies carry the `Secure` attribute.
HttpOnly attribute
Cookies that look session or authentication related carry `HttpOnly`.
SameSite attribute
SameSite values observed on cookies: Strict, Lax, None, invalid or absent.
Server information exposure
The server does not advertise detailed software versions.
DNSSEC
The zone is signed with DNSSEC (a DS record exists).
Web Application Firewall
WAF detection restricted to vendor-specific public signatures. No payload is ever sent.
security.txt
A security contact policy is published.
Spoofing exposure
Combined view of SPF and DMARC on a domain that has no mail service.
VeriFixScan reviews configuration observable from outside. It is not a penetration test, a vulnerability scanner, a malware scanner or a CVE scanner: it never probes for weaknesses, never sends a payload, never submits a form and never attempts to sign in. A clean report here means the settings it can read look right — it is not a statement that your site cannot be attacked.
Enter your website address and VeriFixScan analyses it straight away. No account, no installation, nothing to add to your site.
Frequently asked questions
- What does a website security checker do?
- It reads the configuration your site presents publicly — response headers, the TLS handshake, cookie attributes, DNS records and published files — and reports what each one contained. The result describes how your site is set up, seen from outside.
- Is this a vulnerability scan?
- No. Nothing is probed, injected or fuzzed, no payload is ever sent, no form is submitted and no sign-in is attempted. VeriFixScan reads what your server hands to any ordinary request, and reports that.
- How do I check whether my website is set up securely?
- Run a scan and read the security findings. They name the headers your site sends and the ones it omits, the TLS versions still accepted, the attributes on your cookies and what your server discloses about its own software.
- Does VeriFixScan try to break into my site?
- Never. It behaves like a polite visitor: it requests pages, reads the responses and stops there. It respects robots.txt, it does not work around bot protection, and it holds no credentials for your site.
- Which security headers should my site be sending?
- The ones browsers enforce on your visitors' behalf: a Content-Security-Policy, a framing restriction, Strict-Transport-Security, and a referrer policy. Each is reported as present or absent with the value observed, so you can see what is actually being sent.
- Does it check my certificate and TLS version?
- Yes. The protocol versions the server still accepts are reported separately from whether the certificate covers both the apex and the www hostname — two different answers a padlock icon cannot give you.
- Can it tell me whether my site has been compromised?
- No. Detecting a compromise means inspecting code, logs and stored data, none of which is readable from outside. This reports configuration, and a well-configured site can still have been broken into.
- Are the security findings in the free scan?
- The free scan reports on the sample of pages it reaches, security findings included. A full crawl covers far more of the site and therefore more of the cookies and headers it really serves.