How I Built an Automated Web Security Scanner — How It Works and How Your Website Benefits From It

Most websites online today have security loopholes that even most developers would consider negligible and most website owners overlook entirely. The thing is, these overlooked and neglected tiny loopholes could be exactly how an attacker gets access to your system. We are not going to talk about what an attacker can do once they are in.

What we are talking here is about is a tool I built that helps website owners detect and find these small loopholes before an adversary does.

What the Scanner Checks

The scanner checks a set of HTTP security headers, your SSL certificate, your DNS email authentication record, and whether sensitive files are accidentally exposed to the public. These are not exotic vulnerabilities. They are basic controls that are either present or they are not, and most websites are missing several of them.

Here is what each one does and why it matters.

Content-Security-Policy

The browser has no way of knowing which scripts on your page are intentional and which were injected by an attacker unless you tell it. CSP is that instruction. It defines exactly which sources of content the browser is allowed to load. Anything not on the list gets blocked before it ever runs.

Without it a single unsanitised input anywhere on your site is enough for an attacker to run code in your users' sessions without them knowing. CSP does not fix the vulnerability. It stops the damage when a vulnerability gets exploited.

Strict-Transport-Security

Every first visit to a domain without this header starts with an unencrypted HTTP request even if your server immediately redirects to HTTPS. That moment before the redirect is a window. On any shared network an attacker can intercept it, position themselves between the user and your server, and read everything that follows in plain text.

HSTS closes that window. It tells browsers to only ever use HTTPS for your domain from that point forward. No initial HTTP request. No window to exploit.

X-Frame-Options

Without this header your website can be embedded invisibly inside another page. An attacker builds a convincing interface, loads your site underneath it, and tricks users into clicking buttons on your site without realising it. They are authenticated. The action executes. They have no idea it happened.

One header prevents the entire attack.

X-Content-Type-Options

Browsers try to be helpful. When a file does not match what the server says it is the browser will inspect the content and decide for itself how to handle it. An attacker can exploit this — uploading something that looks like an image but runs as a script once the browser makes its own assessment.

nosniff ends that. The browser trusts the declared type and nothing else.

Referrer-Policy

When a user leaves your site the browser sends the URL they came from to wherever they go next. That URL might contain a password reset token. A session identifier. An internal path. It lands in server logs you have no control over.

Referrer-Policy controls what gets sent. The right configuration means only the domain travels not the path, not the token, not the query string.

SSL/TLS Certificate

The scanner connects directly to your server and inspects the certificate. It checks that it is valid, that it covers the correct domain, and how many days remain before it expires. Certificates within 30 days of expiry get a warning. No certificate at all is a critical failure — nothing else on the scan matters if your traffic is unencrypted.

DMARC

Without a DMARC record anyone can send an email that appears to come from your domain. Your domain name. Your CEO's address. Your support inbox. Receiving mail servers have no instruction from you about what to do with it — so they often deliver it.

DMARC is a DNS record that changes that. It tells receiving servers what to do with mail that fails authentication. The scanner checks whether it exists and whether the policy is actually enforcing anything because a DMARC record set to monitor-only provides no real protection at all.

Exposed Sensitive Files

The scanner checks whether /.env and /.git/config are publicly accessible on your server. These files should never be reachable from the internet. An exposed environment file means your database credentials, API keys, and every other secret your application depends on is readable by anyone who knows to look. An accessible git configuration means your source code history may be recoverable — including things that were committed and later deleted.

The check uses content pattern matching not just HTTP status codes. Some servers return a 200 response for every path whether the file exists or not. The scanner validates the actual content of the response to avoid false positives.

How It All Runs

All checks run simultaneously. The result is a score, a grade from A to F, and a specific list of what passed and what did not — with a plain-language explanation for each finding. Every scan is stored and retrievable.

Most of the fixes that come out of a scan are configuration changes. A header added to your nginx config. A DNS record updated. None of them require changes to your application code. Most take minutes once you know what needs doing.

The scanner tells you exactly what steps you need to take to improve your website’s security posture.

https://webscan.christianoguine.be — try it on a domain you own or have permission to test.

https://github.com/christian-oguine/web-security-scanner — source code under MIT license.