Guides · ← All guides
What a Website Security Assessment Actually Tests
Last updated: October 13, 2026 · 9 min read
"We should get a security assessment" is easy to say and hard to picture. What does the scanner actually do once you point it at your site? Most owners imagine something cinematic. The reality is more methodical, and honestly more interesting: an assessment is the attacker's first hour, replayed against your site on purpose, while you watch.
To make this concrete, let's walk a scan through a fictional site: call it harborlightbooks.example, a small online bookstore. Fictional domain, but every step below is exactly what a real assessment does, in the order it does it. By the end you'll know what you're buying (or running), what each finding actually means, and which ones deserve your attention first.
Phase 1. Reconnaissance: drawing your map before the attacker does
Nothing gets "tested" in phase one. The assessment just looks, the way anyone on the internet can look, and builds a map. DNS records: what IP addresses answer for your domain, where your mail goes, what text records you've published. Subdomains, pulled from certificate transparency logs (crt.sh is the public tool for this; every certificate issued for your domain is logged there, permanently, for anyone to read). And technology fingerprinting: the server software, framework, and CMS your site advertises in its headers.
On our fictional bookstore, recon might turn up something like this: the main shop on one IP, a mail server on another, and two subdomains the owner half-forgot: staging.harborlightbooks.example and old.harborlightbooks.example. The headers announce Server: nginx/1.18.0 and X-Powered-By: PHP/7.4.3.
Two findings before a single "test" has run. Staging servers are the classic: unmaintained, unpatched, often guarded by weaker credentials than production, and trusted by your main domain's cookies. And the version banners are a gift to attackers. They turn a blind guessing game into a lookup. PHP 7.4 reached end of life in November 2022; advertising it tells an attacker exactly which shelf of known vulnerabilities to reach for. Recon is where assessments quietly earn their keep: most owners are surprised by their own footprint.
Phase 2. Port scanning: knocking on every door
Next the assessment checks which network ports answer on your server's IP. Think of it as walking around the building trying every door handle. Your web server needs ports 80 and 443. That's the list. It probably does not need port 22 (SSH), 3306 (MySQL), or 6379 (Redis) reachable from the entire internet, yet assessments find them open constantly, because a firewall rule was never tightened after a debugging session, or a cloud security group was left at its default.
The tool of record here is nmap, and its output reads like a short inventory:
PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 3306/tcp open mysql <-- why is this answering the whole internet? 6379/tcp open redis
Every open port is a service an attacker can now probe directly, skipping your web application entirely. The MySQL line above is the one that makes experienced testers wince. It's the exact shape of the January 2017 MongoDB ransom wave, when attackers scanned the internet for databases left open to the world, wiped tens of thousands of them, and replaced the data with ransom notes. Different database, same mistake: a datastore port that should never have faced the public internet. The fix is usually a one-line firewall change or a cloud security-group edit. Findings like this are rated high or critical not because they're sophisticated, but because exploitation is trivial and the blast radius is your entire dataset.
Phase 3. TLS analysis: checking the armored truck
Phase three inspects the encryption layer: the certificate and how it's configured. Is it valid and unexpired? Does the chain of trust verify on real clients, not just the tester's browser? Are outdated protocol versions (TLS 1.0, TLS 1.1) still enabled? Are weak cipher suites accepted?
TLS findings feel boring until they aren't. The single most common TLS finding in the wild is the expired certificate: renewal automation breaks silently (a changed DNS record, a revoked API token, a cron job on a decommissioned server) and nobody notices until visitors hit a full-page browser warning. And chain problems are sneakier: a missing intermediate certificate works fine in your browser, which cached it from an earlier visit, and fails inside your customer's API integration or their mobile app. The assessment catches both because it verifies the chain the way a stranger's machine would, not the way yours does.
One more thing this phase checks, and it's worth knowing the history: protocol versions. TLS 1.0 and 1.1 have known weaknesses (BEAST, POODLE), PCI DSS set a hard deadline of June 30, 2018 to migrate off them for anyone handling card data, and RFC 8996 formally retired both in March 2021. If your server still negotiates them in 2026, it's not a compatibility feature anymore. It's a finding.
Phase 4. Web security audit: the headers and the leaks
Now the assessment reads your HTTP responses the way a browser does, looking for the defensive headers browsers will enforce on your behalf: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and the Secure and HttpOnly flags on cookies. A quick curl -I https://harborlightbooks.example on our fictional shop might return a response with none of them present.
Missing headers don't mean you're breached. They mean you're declining free, standardized protections against entire classes of attack (clickjacking, protocol downgrade, cookie theft) that cost a few configuration lines to enable. We flag them as low or medium for exactly that reason: cheap to fix, real protection gained.
The same phase hunts information disclosure, which is the polite term for your server gossiping about itself. Stack traces on error pages. Framework version banners. Debug toolbars left on in production. Each one hands an attacker a precise inventory: which software, which version, which database. A banner reading Server: Apache/2.4.49 isn't just a version string. It's a pointer to a specific set of known CVEs, including the path-traversal flaw catalogued as CVE-2021-41773 that affected exactly that build. The fix is unglamorous: generic error pages, banners off, debug mode off outside development.
Phase 5. Directory discovery: the attic check
The last phase probes for exposed paths and files: admin panels, backup files (.bak, .zip, .sql), .git directories, configuration files, directory listings. This is the phase that most often produces the finding that makes an owner's stomach drop.
Picture the fictional bookstore's scan finishing with one line: https://harborlightbooks.example/shop-backup.zip — 200 OK, 41 MB. A backup somebody made during a hurried Friday deployment, sitting in the web root for eight months. Download it and you have the code, the config, and quite possibly a database dump with customer records. No cleverness required on the attacker's part — just a scanner asking for common filenames and a server saying "here you go."
An exposed .git directory is the same story with a worse ending: it can let an attacker reconstruct your entire source tree, including secrets committed months ago and later "removed" (git never forgets; that's the point of version control). These are the findings rated critical, because they're one download away from full compromise.
What an assessment is not
A standard assessment is read-only: it observes and reports, it doesn't exploit. That boundary matters, because it defines what the report can't tell you. It won't find business-logic flaws: the coupon code that can be reused infinitely, the price parameter you can edit in your own browser's request. It won't test your employees against phishing. It won't review your source code for injection flaws or audit who has access to what inside your admin panel.
Those need human-led penetration testing: testers who take the assessment's map and start chaining findings together, thinking the way an attacker thinks. The relationship between the two is simple. The assessment is the first hour of every attack, automated and repeatable. The pentest is what happens after that hour, creative and adversarial. Run assessments continuously. Bring in pentesters for what matters most to your business.
How often to run one
After every major deployment, at minimum. That's when new misconfigurations are born. Plus a quarterly rhythm for the baseline. If you process card payments, note that PCI DSS requires quarterly external vulnerability scans by an approved scanning vendor, so "when we get around to it" isn't compliant there. And between scheduled runs, drift matters: the backup file, the debug flag, the firewall rule somebody loosened at 11 PM to fix an incident and never tightened. That's the argument for continuous scanning — the fundamentals decay, and the scan is how you notice.
The takeaway
A security assessment isn't magic. It's a systematic check of the fundamentals, run the way an attacker would run them, in the open, with a report at the end instead of a ransom note. Run one on a schedule, work the findings top-down by severity, and re-scan to verify the fixes. The goal was never a perfect score. It's knowing your exposure before someone else maps it for you.
Frequently asked questions
What does a website security assessment actually test?
Five phases: reconnaissance (your DNS, subdomains, and tech footprint), port scanning (reachable services like SSH or databases), TLS analysis (certificate validity, protocols, ciphers), web security audit (security headers, cookie flags, information leaks), and directory discovery (exposed admin panels, backups, .git directories). It's read-only: it observes and reports without exploiting anything.
Is a security assessment the same as a penetration test?
No. An assessment is the systematic, mostly automated check of the fundamentals: the attacker's first hour, replayed on purpose. A penetration test adds human testers who chain findings, probe business logic, and attempt controlled exploitation. Use assessments continuously and pentests for your highest-value targets.
How often should I run a security assessment?
After every major deployment at minimum, plus quarterly. Card payments bring PCI DSS into play, which mandates quarterly external scans. Continuous scanning covers the drift in between: the misconfigurations that appear at 11 PM and never get reverted.