We Scanned Our Own Website With Our Free Vulnerability Scanner

Protego launched in January 2026. In February, we shipped a free vulnerability scanner and told readers to run it against their own sites before something went wrong. It took us until August to actually run it against ours.

That gap is common, and it is also the point of this post. Building a security tool does not make you immune to the things the tool checks for, and the only way to find out is to actually run it. So this week we did: a full scan of protego.me, deep scan and cloud checks included, the exact same scan any visitor can run for free right now.

How the scan works

The scanner checks the things that quietly go wrong on a website without anyone noticing: missing security headers (Content-Security-Policy, Strict-Transport-Security, and others), cookies set without the Secure or HttpOnly flags, SSL/TLS certificate health, CORS configuration, DNS-level email protections like SPF and DMARC, and a deeper pass that probes for exposed files such as `.env` or `.git`, outdated JavaScript libraries with known vulnerabilities, and CVEs tied to whatever software the site reveals in its response headers. We have written a full breakdown of every check it runs in Free Website Vulnerability Scanner: Check Your Security Headers, SSL, and More if you want the complete list.

None of it requires an account, and none of it touches anything behind a login. It reads what any visitor’s browser already reads.

The result: a D

protego.me scored 59 out of 100. Grade D. For a cybersecurity blog, that is not a comfortable number to publish, but publishing it is the point: a security company’s own site having real gaps is normal, not a scandal, as long as you find them and fix them instead of assuming they do not exist.

Some of the findings were genuinely worth fixing. One of them turned out to be a bug in the scanner itself, which was the more interesting problem.

What we actually fixed

Outdated dependencies with known CVEs

protego.me runs on Next.js, our web framework, plus a handful of supporting libraries. Software has version numbers for a reason: newer versions patch bugs, and some of those bugs are security bugs with public CVE records anyone can look up. We were several versions behind on our framework and an image-processing library, both with fixed, publicly known issues ranging from denial-of-service conditions to response-cache poisoning. Nothing we found suggests either was ever exploited against us, but "nothing we found suggests" is exactly the position you do not want to be arguing from. We patched everything with a straightforward, non-breaking upgrade path, verified the site still built and passed its full test suite, and shipped it.

A bug that penalized us for someone else’s vulnerability

This was the interesting one. Part of the scan tries to identify what software a site is running from its response headers, then checks that software’s version against a public vulnerability database. protego.me’s hosting platform sends back a header that just says "Vercel", no version number attached, because a hosting platform is not a piece of versioned software the way a web server is.

The scanner’s fallback logic took that bare word "Vercel" and searched the vulnerability database for it anyway. The database does a keyword search, not an exact product match, so it returned old, unrelated CVEs in other software that happened to mention the word "Vercel" somewhere in their description, mostly older Next.js bugs referencing where people commonly deploy it. The scanner then treated those as real findings and docked score points for them.

In other words: the tool built to catch real vulnerabilities was capable of inventing one out of a coincidence in search text, and doing it to every site hosted on Vercel, Cloudflare, Netlify, or any platform whose server header does not include a version number, not just ours. We fixed it so the scanner only looks up a CVE when it has an actual version number to check, and skips the lookup entirely otherwise. A wrong "you have a known vulnerability" result is worse than no result at all: it either sends a business owner into a panic over nothing, or it teaches them to stop trusting the tool’s real findings.

Two smaller, real fixes

A cookie we set to remember a visitor’s cookie-consent region was missing the Secure flag, meaning it could technically be sent over an unencrypted connection. We added it. We deliberately did not add the HttpOnly flag to that same cookie: a small script on the page needs to read its value to decide whether to show a consent banner, and the cookie itself holds nothing more sensitive than a yes-or-no region flag, so hiding it from that script would break the feature for no real security gain.

We also added a `/.well-known/security.txt` file, a small, standardized text file defined in RFC 9116 that tells anyone who finds a real problem on our site exactly how to report it responsibly, instead of guessing at a contact email or posting it publicly first. Every site should have one, and most do not.

What is still open

This was not a one-time fix-everything pass. A handful of lower-severity findings remain on our list. We are working through them in order of actual risk rather than rushing all of them at once, the same advice we would give anyone reading this about their own site. We are not listing them here, for the same reason you would not publish a list of your house’s unlocked windows before you have gotten around to fixing them.

Why any of this actually matters

Framework-level bugs like the ones we patched can, depending on the specific issue, let an attacker crash a site, serve a cached response to the wrong visitor, or in the worst cases run code that should not run. You do not need to be targeted specifically. Automated scanning for exactly these known, patched bugs is constant across the entire internet, and "we had not gotten around to updating" is not a defense a scanner cares about.

The scanner bug matters for a different reason. A tool that grades security posture has to be trustworthy in both directions: it needs to catch real problems, and it needs to not invent fake ones. A false D grade caused by a search-text coincidence could push a small business owner to spend money fixing something that was never broken, or worse, teach them the tool cries wolf and they should ignore its next warning, which might be real.

Run it on your own site

The scanner is free, takes under 15 seconds, and needs no signup: protego.me/tools/vulnerability-scanner. If you want the full list of everything it checks, see Free Website Vulnerability Scanner: Check Your Security Headers, SSL, and More.

Frequently asked questions

Is protego.me completely secure now?

No, and any company claiming their site is "completely secure" after one round of fixes is telling you they do not understand the problem. We fixed what this scan found and are working through the rest. Security is an ongoing process, not a state you reach once.

Does the scanner store or see my data when I scan my own site?

The scan only reads what is already public: your site’s response headers, its published files, its DNS records. It does not require a login and does not access anything behind one.

What is security.txt, and does my site need one?

It is a standardized file at `/.well-known/security.txt` that tells security researchers how to report a vulnerability to you directly, defined in RFC 9116. Without one, someone who finds a real problem on your site has to guess at a contact method, which either delays the report or pushes them toward posting it publicly instead.

Why did an unversioned header cause a false CVE match?

Vulnerability databases like NVD are searched by keyword, not exact product match. Feeding a search engine a bare word like a platform name, with no version number attached, returns anything that mentions that word, which is a fundamentally different thing from returning vulnerabilities in that actual product.

How often should I scan my own website?

After any meaningful change (new dependencies, new features, infrastructure changes) and on a recurring basis even when nothing has changed, since new CVEs are published against existing software constantly. A quarterly scan is a reasonable minimum for a small site; monthly is better if you are actively shipping changes.

The honest takeaway

We are not now secure in some final sense. We finally checked, found real things, fixed what we could immediately, and are being upfront about what is still in progress instead of quietly patching it and saying nothing. If you run a website and have never pointed a scanner at it, that is the gap this post is really about.