Methodology
97 checks, in the open
Everything a scan looks at, grouped by area, with what a failure means for you. All checks are read-only.
Web security
Security headers, HTTPS enforcement, cookies and cross-origin rules of the website.
| Check | Why it matters |
|---|---|
| Site is served over HTTPS | Every password, cookie and form entry crosses the internet unencrypted. Browsers mark the site 'Not secure', which costs trust and conversions, and search engines rank it lower. |
| HTTP redirects to HTTPS | Visitors who type the bare address land on the unencrypted version of the site, where logins can be intercepted and pages tampered with. |
| HSTS enabled with a long lifetime | Without HSTS, the first visit can be intercepted on public Wi-Fi and silently kept on unencrypted HTTP (SSL stripping), exposing logins and session cookies. |
| Content-Security-Policy restricts scripts | CSP is the safety net against cross-site scripting (XSS), the most common web vulnerability. Without it, one injection bug lets attackers steal sessions, skim card details or deface pages. |
| MIME sniffing disabled (X-Content-Type-Options) | Browsers may treat uploaded files or API responses as scripts, which turns file uploads into an XSS vector. |
| Clickjacking protection (X-Frame-Options / frame-ancestors) | Other sites can load your pages in an invisible frame and trick users into clicking buttons they cannot see (clickjacking) - for example confirming a payment or changing settings. |
| Referrer-Policy set | Full URLs - including tokens or personal data in query strings - are sent to every external site users click through to. |
| Permissions-Policy set | Embedded third-party code (ads, widgets) can ask visitors for camera, microphone or location access in your name. |
| Cookies flagged Secure, HttpOnly and SameSite | A cookie without Secure can be sent over plain HTTP, where an attacker on the same network can steal it and log in as the user. |
| Server software versions hidden | Exact version numbers let attackers look up which public exploits work against your server, and automated tools target vulnerable versions specifically. |
| Cross-origin requests restricted (CORS) | Any website a logged-in user visits can read their account data from your site in the background - personal data, API keys, anything the user can see. |
| security.txt published | Security researchers who find a problem have no clear way to tell you, so the report may never arrive - or the issue is disclosed publicly first. |
| No mixed content on HTTPS pages | A script or style loaded over HTTP can be replaced by anyone on the network path - public Wi-Fi, a compromised router - and then controls the page. Browsers block such content, so parts of the page may already be broken for visitors. |
| Forms submit over HTTPS | Form data sent over HTTP - logins, contact details, payment data - can be read and changed by anyone on the network path. Browsers also warn visitors before they submit. |
| CDN scripts protected with Subresource Integrity | If a CDN account or file is ever compromised, every site that loads it without an integrity check runs the attacker's code - card skimmers have spread exactly this way. |
| CMS version not public | Attackers match the exact CMS version against published vulnerabilities and target sites running affected versions automatically. |
| CMS user names not public | With the login names public, password guessing needs only the password. Admin accounts named after the site or the owner are the first targets. |
| WordPress XML-RPC disabled | XML-RPC lets attackers test hundreds of passwords in one request and is used to amplify attacks against other sites. |
Data exposure
Configuration files, backups and source code that should never be public.
| Check | Why it matters |
|---|---|
| Directory listing disabled | Anyone can browse folder contents - uploads, backups, logs and files that were never meant to be linked - and search engines may index them. |
| Debug error pages turned off | Debug pages show source code, file paths, environment variables and often database passwords to anyone who triggers an error; some let visitors execute code on the server. |
| No public CMS debug log | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.git/HEAD | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.env | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.aws/credentials | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /wp-config.php.bak | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /backup.sql | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.htpasswd | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /actuator/env | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /server-status | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /phpinfo.php | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.DS_Store | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.vscode/sftp.json | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.git/config | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.env.local | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.env.production | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.ssh/id_rsa | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.npmrc | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /docker-compose.yml | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /web.config | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /.svn/wc.db | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /backup.zip | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /backup.tar.gz | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /database.sql | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /server-info | Anyone who requests the file gets it - automated bots look for exactly these paths within hours of a site going live. Leaked credentials lead straight to a data breach. |
| No public /phpmyadmin/ | Administration logins on the open internet are found by scanners within hours and attacked with password lists and published exploits. One weak or reused password gives an attacker the database or the server. |
| No public /adminer.php | Administration logins on the open internet are found by scanners within hours and attacked with password lists and published exploits. One weak or reused password gives an attacker the database or the server. |
| No public /manager/html | Administration logins on the open internet are found by scanners within hours and attacked with password lists and published exploits. One weak or reused password gives an attacker the database or the server. |
TLS & certificates
Certificate validity and trust, key strength and protocol versions.
| Check | Why it matters |
|---|---|
| Certificate within its validity period | Browsers show a full-page security error instead of the site. Most visitors leave, and APIs and payment integrations stop working. |
| Certificate valid for 30+ more days | When the certificate expires, the site goes down for every visitor until it is renewed. |
| Certificate covers the host name | Visitors get a 'your connection is not private' warning, which looks exactly like an attack. |
| Certificate chain trusted by browsers | Browsers and apps refuse the connection or show a warning; some clients silently fail. |
| Certificate key at least 2048-bit | A short key can be broken by a well-funded attacker, who could then impersonate the site. |
| Certificate signed with SHA-256 or better | Certificates signed with SHA-1 or MD5 can be forged and are rejected by modern browsers. |
| TLS 1.0 disabled | TLS 1.0 has known attacks (BEAST, POODLE variants) and is forbidden by PCI DSS; keeping it enabled can fail a compliance audit. |
| TLS 1.1 disabled | TLS 1.1 is deprecated (RFC 8996) and fails PCI DSS and most security baselines. |
| TLS 1.3 supported | TLS 1.3 connects faster and removes legacy weaknesses; without it, every visitor uses an older protocol. |
Email security
SPF, DMARC, DKIM, MTA-STS: protection against spoofed mail in your name.
| Check | Why it matters |
|---|---|
| SPF record published | Without SPF, anyone can send mail that appears to come from your domain. Phishing and invoice fraud in your name damage customers' trust, and your real mail is more likely to land in spam. |
| SPF rejects unlisted senders | +all explicitly authorizes the whole internet to send as your domain - worse than no SPF. |
| SPF within the 10-lookup limit | Above 10 DNS lookups SPF evaluation fails with an error, so receivers treat it as absent and your legitimate mail may fail DMARC. |
| SPF avoids the deprecated ptr mechanism | The ptr mechanism is deprecated and some receivers ignore it, so the senders it describes may fail SPF. |
| DMARC record published | DMARC is what makes SPF and DKIM enforceable. Without it, spoofed mail in your name reaches inboxes, and since 2024 Google and Yahoo require DMARC from bulk senders. |
| DMARC enforces quarantine or reject | p=none only observes. Spoofed mail is still delivered, so customers can still receive phishing that looks like it comes from you. |
| DMARC protects subdomains | Attackers can spoof any subdomain (billing.example.com) even though the main domain is protected. |
| DMARC reports collected | You cannot see who sends mail in your name, so abuse and misconfigured senders go unnoticed. |
| DKIM signing key published | Unsigned mail is easier to forge and more likely to be filtered as spam; DMARC then depends on SPF alone, which breaks on forwarding. |
| DKIM key at least 2048-bit | Short DKIM keys can be cracked, letting an attacker sign mail as your domain. |
| MTA-STS enforces encrypted delivery | Mail to you can be downgraded to unencrypted delivery by an attacker in the network path, exposing its contents. |
| SMTP TLS reporting enabled | You do not learn when other servers fail to deliver to you securely. |
Network & services
Databases, remote access and other services reachable from the internet; blocklist status.
| Check | Why it matters |
|---|---|
| No plaintext FTP | FTP logins travel in clear text and are captured by anyone on the path; FTP servers are also a frequent brute-force target. |
| Not on spam or malware blocklists | Mail from a listed address is rejected or lands in spam, and a listing usually means the server was compromised or abused. |
| telnet (23) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| smb (445) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| mssql (1433) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| cpanel (2083) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| whm (2087) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| mysql (3306) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| rdp (3389) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| postgresql (5432) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| vnc (5900) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| redis (6379) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| elasticsearch (9200) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| webmin (10000) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| memcached (11211) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
| mongodb (27017) not exposed | Internet-wide scanners find an open service within minutes. Exposed databases and remote-access services are the most common starting point of data breaches and ransomware. |
DNS & attack surface
DNS hygiene, subdomains, takeover risks and domain registration.
| Check | Why it matters |
|---|---|
| CAA record restricts certificate issuance | Any of the hundreds of certificate authorities may issue a certificate for your domain; CAA limits that to the ones you actually use, reducing mis-issuance risk. |
| Zone transfers refused (AXFR) | The full list of host names - including internal, staging and forgotten systems - is handed to anyone who asks, which saves attackers the reconnaissance. |
| DNSSEC enabled | Forged DNS answers can redirect visitors or mail to an attacker's server without any warning. |
| Domain registration valid for 30+ days | An expired domain takes the website and all mail offline, and the name can be bought by someone else. |
| No subdomain takeover risk | An attacker can claim the abandoned resource and publish anything under your domain - convincing phishing pages, malware, or scripts that steal cookies of your main site. |
| No dangling CNAME records | If the alias target becomes registrable, whoever registers it controls your subdomain. |
| No public development or admin hosts | Development, staging and admin systems are typically less patched and protected than production, and often contain real data - a common entry point. |
Known vulnerabilities
Published CVEs affecting the software versions your servers reveal.
| Check | Why it matters |
|---|---|
| No WordPress plugins or themes with known vulnerabilities | Vulnerable plugins are the most common way WordPress sites are taken over: bots try published flaws against every site that loads the plugin, often within days of disclosure. The result is defaced pages, spam, card skimmers or a stolen customer database. |
| WordPress plugins and themes maintained and up to date | Plugin updates often fix security issues before they appear in any vulnerability database; attackers compare releases to find what was fixed. |
| No known CVEs in disclosed software versions | Published vulnerabilities come with public exploit details, and attackers scan for vulnerable versions automatically. Outdated server software is one of the top causes of breaches. |
| No actively exploited vulnerabilities (CISA KEV) | Criminal groups are exploiting these vulnerabilities right now, often within days of publication and frequently to deploy ransomware. An exposed vulnerable server is likely to be found by automated attack tools. |
| Software versions still receive security fixes | The vendor no longer fixes this release line. Every vulnerability discovered from now on stays open for good, and compliance frameworks (PCI DSS, ISO 27001, cyber insurance questionnaires) treat unsupported software as a finding on its own. |
| Software on the latest patch release | Patch releases are how vendors ship security fixes. Running an older patch means missing fixes that are already public - attackers compare releases to find what was fixed. |