Log4Shell (CVE-2021-44228) was a wake-up call for anyone running a website. A single vulnerable library opened the door to remote code execution on servers around the world. The lesson wasn't that you need to panic about every dependency. It was that routine, passive checks can catch the kinds of problems that actually get exploited. You don't need to attack your own site or install agent software. You just need to look at what your site already exposes and fix the gaps. This post walks through the most practical checks you can run right now, without a budget or a security team.

Outdated JavaScript Libraries with Known CVEs

Many sites load JavaScript from public CDNs or bundle older versions of popular frameworks. If a library has a published CVE and you are still serving an unpatched version, an attacker can use that flaw against you. Log4Shell was a library-level vulnerability, and the same pattern happens in front-end code. Passive scanners can read the version strings your site sends in script tags or HTTP responses and cross-reference them against CVE databases. You get a list of which libraries are outdated and what the fix is.

What to do about it

  • Make an inventory of every JavaScript library your site loads, including third-party widgets and analytics scripts.
  • Update each library to the latest patched version. Check the library's changelog for breaking changes.
  • After updating, re-scan to confirm the CVEs are gone. A single missed script can still be a risk.

Missing HTTP Security Headers

HTTP response headers are instructions from your server to the browser about how to handle your content. Two of the most important are Content-Security-Policy (CSP) and Strict-Transport-Security (HSTS). CSP tells the browser which sources of scripts and styles are allowed, which can block injection attacks. HSTS forces browsers to only connect over HTTPS, even if the user types a plain HTTP URL. Without them, your site relies on the user's browser defaults, which are often insecure.

A security headers check reads the headers your server actually sends and flags missing or weakly configured ones. The same check can also look at frame policies (X-Frame-Options) and MIME-sniffing protections (X-Content-Type-Options). These are small fixes that close real attack paths.

Weak TLS Configuration or Expiring Certificates

Transport Layer Security is the encryption layer between your server and visitors. If your TLS settings allow old protocols or weak ciphers, an attacker can downgrade or decrypt traffic. An expiring certificate is a simpler problem: it causes browser warnings that drive visitors away and can be used in phishing pages that mimic your site before the cert expires.

What a TLS check covers

  • Certificate validity and expiration date
  • Supported protocol versions (the current standards)
  • Cipher strength and ordering
  • Whether the certificate chain is complete

Running a quick SSL/TLS checker a few times a year will catch expiration long before it becomes a crisis. Renew your certificate and re-scan to verify the new one is properly installed.

Exposed Files and Directory Listings

Your web server might be serving files you never intended to make public: backup archives, configuration files, .git directories, or admin panels with default paths. Attackers probe for these constantly. A passive scan reads the paths your site exposes and flags common sensitive endpoints. You don't have to guess; the scanner will show you the URLs that returned a successful response.

Review that list and remove or password-protect anything that shouldn't be public. After cleaning up, re-scan to make sure the files are gone. Repeat this after every major deployment.

Missing Email Authentication Records

SPF, DKIM, and DMARC are DNS records that tell receiving mail servers whether an email claiming to be from your domain is legitimate. Without them, attackers can spoof your domain and send phishing emails that look like they came from you. Your visitors, partners, and even your own staff can be targeted.

An email check reads your domain's DNS records and reports which of the three standards are missing or misconfigured. DMARC is the policy record that tells receivers what to do with messages that fail authentication. If you don't have a DMARC record, start with a monitoring policy (p=none) to see what spoofing is already happening, then move to quarantine or reject once you have visibility.

Putting it All Together with a Free Scan

Each of these checks can be done separately, but running them together gives you a single view of your site's external security posture. A passive scan reads what your site already exposes and does not attack it. No account or payment is needed. You can enter your site's address into a free website security scanner and get back a report with findings explained in plain language. The checks cover HTTP security headers, TLS configuration, cookies, exposed files, and more. There are also dedicated tools for SSL/TLS, security headers, email authentication, JavaScript library vulnerabilities, WordPress setups, browser fingerprint leaks, file malware scanning, phishing URL detection, and password breach checks. Run the scan now, fix the issues it finds, then re-scan after your changes. That cycle is the practical, repeatable habit that keeps your site safer than it was yesterday.