Free Website Security Scan: What It Checks and Why You Need One

What a free scan really does

A website security scanner is an automated tool that probes your site from the outside — the same vantage point an attacker has — and reports the weaknesses it can detect without your source code. A good free scan is a fast, honest first look. Here's what it checks, what it can't, and how to use the results.

What a scan checks

Transport security (TLS/SSL)

• Valid, non-expired certificate
• Modern protocol versions (TLS 1.2+), weak ciphers disabled
• HTTP correctly redirecting to HTTPS

Security headers

The scanner reads your response headers and flags what's missing:

Strict-Transport-Security
Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
Referrer-Policy

Missing CSP and HSTS are the most common findings and the highest leverage to fix.

Exposed files and endpoints

It probes for files that should never be public:

/.env
/.git/config
/backup.zip
/wp-config.php
/.DS_Store

A reachable .env or .git directory is a critical, instant finding.

Cookie configuration

Whether session/auth cookies carry HttpOnly, Secure, and SameSite — the flags that stop token theft and CSRF.

Injection and input handling

Deeper scanners actively test inputs for SQL injection and cross-site scripting (XSS) by sending crafted payloads and observing responses.

Known-vulnerable software

Fingerprinting the CMS, framework, or library versions and matching them against public CVE databases.

BaaS misconfigurations

Modern scanners check whether your Supabase/Firebase rules actually deny unauthorized access — a category traditional scanners miss entirely.

What a free scan can't find

Be honest about the limits. Automated scanning is weak at:

• Business-logic flaws — e.g., applying a coupon twice, or skipping a payment step. A scanner doesn't know your rules.
• Complex authorization (IDOR) at depth — it can catch some, but full coverage needs context about who should access what.
• Anything behind a login it can't reach without credentials.
• Social engineering and phishing — out of scope by definition.

A scan is the floor, not a substitute for code review on the security-critical paths.

How to act on the results

Prioritize by severity × exploitability, not by count:

1. Critical: exposed secrets/.env, open database, SQLi, auth bypass → fix today.
2. High: XSS, missing CSP, known-vulnerable dependency with an exploit → fix this week.
3. Medium: missing hardening headers, weak cookie flags → fix this sprint.
4. Low/Info: version disclosure, minor misconfig → batch it.

Don't drown in low-severity noise while a critical sits open.

Free vs paid scans

A free scan is perfect for "is anything obviously broken?" A paid scan earns its keep when you have users, revenue, or compliance on the line.

How often to scan

• Before every launch of something new.
• On every deploy if you can automate it — regressions sneak in.
• On a schedule (weekly/monthly) to catch newly disclosed CVEs in your dependencies.

A reasonable workflow

1. Run a free scan to get the lay of the land.
2. Triage by severity and fix criticals immediately.
3. Re-scan to confirm the fix landed.
4. Automate the scan into your deploy pipeline so it never lapses.

Scan it with Troja

Troja's free scan runs 120+ checks — headers, TLS, exposed files, SQLi/XSS, and BaaS misconfigs — against any URL in about 30 seconds, and shows you the threat count up front. Found something? Each issue unlocks a fix prompt you can paste into your AI agent. Start free.