Why I built webcheck.fyi

I built webcheck.fyi because I was repeatedly checking my own sites by hand.

Same list of checks each time: certificate; security headers; cookies; email records; anything left from the build that shouldn’t be in production.

Tools for all of that already exist. Each one does a single job, so checking these things means keeping 6 tabs open. Paste the domain, wait, read a grade, come back, paste it again somewhere else, and try to remember which site I had been on.

The tabs

SSL Labs for the certificate. Paste the host, wait while it tries a pile of ciphers, get a letter. I want that when I am actually arguing about TLS. I do not want it when the question is whether the cert renewed, and whether the site still answers on plain HTTP.

securityheaders.com for the headers. That one is quick. Then I am looking at a grade and a list of names, deciding which missing header matters on this site and which one I can ignore.

Cookies don’t have a proper equivalent. DevTools, Application tab, and I read Secure, HttpOnly, and SameSite off each one. Two cookies is fine. A session, a consent banner, and an analytics cookie is where I start skipping.

Mail is a different place again. MXToolbox, or the DNS host, for SPF, DKIM, and DMARC. Nothing on the homepage tells you this is broken. The site loads, the form sends, and the domain can still be used to send a fake invoice. So this is the check that I often forget or tend to leave until someone asks.

Then I type /.well-known/security.txt myself. A 404 means anyone who finds a problem has to guess who to contact.

Then curl -I, to see if Server or X-Powered-By is naming a version. It takes a few seconds, and I still forget.

I still open these when I want the long version. For a normal deploy they were the rounds: six pastes, six different ways of saying “sort of fine”, and a decent chance I had skipped the mail records or the version header.

Why I keep checking them

The headers are instructions to the browser after the page has loaded. Content-Security-Policy says where scripts, frames, and images are allowed to come from. That matters when a tag or a dependency starts loading something you didn’t add. Frame rules stop another site putting yours in an iframe with a fake button on top. X-Content-Type-Options: nosniff stops the browser deciding a file is a script because the contents looked like one. Referrer-Policy is what stops the full URL of a private page being sent on to the next site.

I needed something that checks all of these and tells me (or my AI) which of them I should fix on the site I just shipped.

Cookies are the login. Without HttpOnly, a script on the page can read the session. Without Secure, the cookie can go out on a connection that isn’t HTTPS. Without SameSite, another site can try to send it with a request. It tends to go wrong in the week a form or a login lands, which is when I am looking at the feature and not at the Application tab.

Email has nothing to do with the page rendering, but it still uses your name. SPF lists the servers allowed to send as you. DKIM signs the message. DMARC is what you tell Gmail to do when those checks fail: deliver it, quarantine it, or reject it. p=none is the setting people put on once, see that their own mail still arrives, and never come back to. The website will not mention it.

security.txt is just a contact at a path that security people already request. No file, and a real report goes to whatever address they can scrape, often the info@ nobody reads. I can check the URL by hand but I usually don’t, unless the result is already on the page with everything else.

The version banner is the small one. X-Powered-By: Express, or a PHP version, is not a break-in. It is a label on every response, and some of those versions have public bugs with notes on how to use them. Removing the header is configuration. Leaving it there is what happens when the check is a command I have to remember to run.

One page

Webcheck is those six checks, once. Address in, a tick to say that you look after the site, and you can turn individual checks off if you don’t care about them this time. It scores what it looked at out of 100, puts the things worth fixing first, and you can copy a summary or a fix prompt back into the editor instead of awkwardly copy pasting the report yourself.

The tick is there so this stays a tool for sites I am responsible for.

It will not try passwords, forms, injections, ports, or hidden files. A high number means those public settings look alright. It does not mean anyone has audited the site. If I need the cipher list, or the full header write-up, SSL Labs and securityheaders.com are still the right tabs. Most deploys just need me to notice that one of the six is wrong, on the sites I actually maintain.

Please check it out at webcheck.fyi, and let me know if it helps you secure your sites and what other features you might find useful for this kind of tool.