About
Security checks anyone can understand
Who built this
Hi, I'm Ibrohim, a student interested in cybersecurity. I built SiteGrade as a hands-on project to learn how websites are actually protected, from TLS certificates to HTTP security headers and email authentication.
Why
Many of the most common website weaknesses aren't complicated bugs. They're missing settings: a header that was never added, a certificate about to expire, a domain anyone can send email from. They're easy to fix once you know about them, but most tools either assume you're a security expert or bury the answer in jargon.
SiteGrade gives a clear grade, explains what each result means in plain English, and tells you exactly what to change.
How it works
When you enter a domain, the server connects to it the same way a browser would and reads only public information: the homepage's HTTP response headers (over HTTPS and HTTP), the TLS certificate, one handshake per TLS version to see which ones are accepted, the public security.txt and robots.txt files, and DNS records (SPF, DMARC, CAA, DNSSEC). Everything runs in parallel and usually takes a few seconds.
For every problem, the report explains what it means and gives ready-to-paste configuration for nginx, Apache, Vercel, Netlify, Cloudflare and Next.js, plus DNS records, generated from what was actually missing.
How grading works
Each check is a pass (full points), warning (partial points) or fail (no points). Weights reflect real-world impact: things every visitor depends on (HTTPS, a trusted certificate, browser protections) count most; defence-in-depth extras like CAA, DNSSEC and security.txt count a little. Informational findings never change the score.
HTTPS
12 pts- Site loads over HTTPS8
- HTTP redirects to HTTPS4
TLS certificate & protocols
22 pts- Certificate trusted and matches the domain10
- Certificate not expiring within 30 days4
- TLS 1.0/1.1 refused, TLS 1.2/1.3 supported5
- Key strength (RSA ≥ 2048, EC ≥ 224)2
- No SHA-1/MD5 signatures1
Security headers
32 pts- Strict-Transport-Security7
- Content-Security-Policy9
- X-Frame-Options / frame-ancestors5
- X-Content-Type-Options5
- Referrer-Policy3
- Permissions-Policy3
Cookies
8 pts- Secure flag4
- HttpOnly flag2
- SameSite attribute2
Information leakage
5 pts- No version in Server header3
- No X-Powered-By and similar headers2
- Detected technologies (informational)info
Email security
12 pts- SPF record ending in -all or ~all5
- DMARC policy quarantine or reject7
DNS security
6 pts- CAA record3
- DNSSEC3
Public files
3 pts- Valid security.txt3
- robots.txt review (informational)info
The total out of 100 becomes a letter grade: A+ (95+, with no failed checks), A (85+), B (70+), C (55+), D (40+) or F below that.
Some problems are serious enough to cap the grade no matter how good the rest is:
- Fat most, when the site can't be loaded over HTTPS.
- Dat most, when the certificate is untrusted or expired.
- Cat most, when the certificate uses a weak key.
- Cat most, when Shodan's public data shows a database reachable from the internet.
- Bat most, when the server still accepts TLS 1.0 or 1.1.
Public exposure data from Shodan can also subtract points (never more than 15 in total): −5 for each database reachable from the internet (MySQL, PostgreSQL, Redis, MongoDB…), −3 for each remote-admin service (SSH, RDP, VNC, Telnet, SMB…), capped at −12 for ports, and −3 for known CVEs (−6 for 5 or more). A site with any penalty can't get an A+. If Shodan has no data or can't be reached, nothing is deducted. Past data breaches are shown for context and never change the grade.
Hacker's View: public data sources
Attackers usually start with reconnaissance from free public sources, so the report shows what they would find. All of this data is public and passive: these services collected it earlier, and looking it up never touches the scanned server. To look things up, the scanned domain and its IP address are sent to the services below. Many thanks to them:
- Shodan InternetDB
Open ports, known CVEs, software (CPEs) and tags for up to two of the site's IP addresses, from Shodan's own earlier internet-wide scans.
- Have I Been Pwned
Public data breaches of the domain: when, how many accounts, and what was leaked. Licensed CC BY 4.0. Shown as context only; it never affects the grade.
- RDAP (via rdap.org)
Domain registration date, expiry, last update and registrar, from the official registry. Very new or soon-expiring domains get a warning.
- Internet Archive Wayback Machine
When the site was first archived, the latest snapshot and roughly how many snapshots exist.
- ipwho.is
Approximate server location, hosting provider and network (ASN) of the site's IP address.
- OpenStreetMap
Map tiles for the server-location map (© OpenStreetMap contributors), displayed with the open-source Leaflet library.
Limitations
This is a quick external check of configuration, not a penetration test. It only looks at the homepage, can't see pages behind a login, and doesn't look for vulnerabilities in the application's code. Some sites also serve different headers to automated tools. A good grade means the basics are in place, not that a site is unbreakable.
How the scanner protects itself
A tool that makes requests to any URL you give it is itself a juicy target. These are the safeguards built in:
Passive only
The scanner behaves like a visitor: it loads the homepage, security.txt and robots.txt, does one ordinary TLS handshake per protocol version, and reads public DNS records. No port scanning, no vulnerability probes, no guessing of paths or passwords. Paths listed in robots.txt are shown, never visited. Open ports and CVEs come from Shodan's existing data, not from scanning.
Strict input validation
Only real public domain names are accepted. Protocols, paths, ports and credentials are stripped; IP addresses and internal names like localhost or .internal are rejected.
SSRF protection on every connection
Every connection, including each redirect and every TLS handshake, resolves DNS and refuses private, loopback, link-local and reserved ranges (10.x, 172.16-31.x, 192.168.x, 127.x, 169.254.x, ::1, fc00::/7…). The check runs inside the socket's own lookup, so DNS rebinding can't sneak in a different address.
Hard limits
Each network request times out after 5 seconds, at most 5 redirects are followed, and only ports 80 and 443 are contacted. The only bodies ever read are security.txt (max 32 KB) and robots.txt (max 64 KB), as plain text.
Legacy TLS stays contained
Testing for TLS 1.0/1.1 needs OpenSSL's security level lowered. That setting is used only for those single test handshakes, which send no data; every other connection uses normal, modern settings.
Rate limiting
Each visitor can run a limited number of scans per few minutes, so the scanner can't be turned into a tool for flooding other sites.
No XSS from scanned sites
Header values, DNS records and file contents from scanned sites are displayed strictly as text, never as HTML. The app itself ships a nonce-based Content-Security-Policy.
Contained clickjacking demo
The demo embeds the scanned page with sandbox="" (no scripts, forms or navigation). Our pages may only frame our own demo page, whose policy, set per request, allows exactly one origin: the site you scanned.
Third-party data is untrusted
Responses from public data sources are fetched over verified HTTPS through the same SSRF-guarded client (5s timeouts, size caps), strictly validated, shortened, and shown as plain text. HTML in breach descriptions is stripped. Results are cached for up to 24 hours, and a source that fails or is rate-limited is simply hidden.
No tracking, no server storage
There's no database. Results exist only in your browser tab, recent scans are saved only in your browser's local storage, and cookie values from scanned sites are discarded.