I built a security scanner, never shipped it, and finally finished the job

SecURL — Sun, 24 May 2026 09:52:24 +0000

I built SecURL about six months ago during a stretch of evenings where I kept hitting the same frustration: running a security scan on a site and getting back either a wall of jargon or a narrow result that only checked one thing. securityheaders.com checks headers. SSL Labs checks TLS. Mozilla Observatory covers a bit more. But nothing gave you the full picture in one pass, ranked by what to actually fix first.

So I built it. SecURL scans a URL and checks HTTP security headers, TLS configuration, DMARC, SPF, DKIM, DNSSEC, third-party script exposure, cookie flags, redirect chains, and more. It gives you an A to F grade and ranks every finding by severity with OWASP references attached. Paste a URL, get a report in about 30 seconds.

The scanner itself worked well. The engine was solid. But the project sat in a state I think a lot of side projects end up in: technically functional, never actually shipped. No marketing presence, no billing system, UX issues I knew about but kept deferring, documentation that existed only in my head.

That is the before.

The finish-up started with the UX problems I had been ignoring. There was a white gap appearing at the bottom of the page on certain viewport sizes. The navigation tab bar was getting truncated because a share button was stealing horizontal space in the same flex row. The recent scans list showed every grade in the same teal colour regardless of whether the site got an A or an F. The version badge in the hero was showing the full internal build string — core version, build hash, app version — fine for me, noise for everyone else.

Copilot helped me move quickly through these fixes. The kind of changes where you know exactly what needs to happen but the back-and-forth of finding the right element, checking what the parent is doing, adjusting the layout — having inline suggestions while you work through it means you stay in flow instead of breaking to look things up. The white gap was a single CSS property once I found the right place. The tab truncation was moving the share button out of the flex row into its own div above the nav. Small things individually, but the app looks significantly more polished now.

The marketing site (securl.online) also needed work. The comparison table footer copy said "active checks" which contradicted the rest of the site explaining that SecURL only makes passive observations — public-response checks, nothing invasive. One line that would have undermined trust with anyone who read carefully.

The after is that SecURL is now actually launched rather than just running.

The UX issues are fixed and shipped. There is a Twitter account (@thisissecurl) with posts going out. A Dev.to presence. A Product Hunt profile. A proper UX review checklist so future deploys go through a structured check before anything ships.

The scanner itself does things most free tools do not. It checks email trust records properly — not just whether DMARC exists but whether the policy is set to quarantine or reject, whether SPF has overly permissive qualifiers, whether DKIM selectors are discoverable. It detects session replay tools and analytics vendors from the third-party script surface. It maps the redirect chain and flags security issues at each hop. The grade system collapses all of that into something a non-security person can act on.

If you want to try it: app.securl.online. Free, no account needed, takes about 30 seconds. Particularly interested to hear from anyone who scans something and gets a result they think is wrong — the engine is still being tuned and real-world feedback is genuinely useful.

What are HTTP security headers — and which ones does your site actually need?

SecURL — Sun, 24 May 2026 09:36:03 +0000

If you run a security scan on your site and it comes back with a wall of warnings about missing headers, the temptation is to either panic or ignore it entirely. Neither helps. Most of these are genuinely straightforward to fix — the tricky part is knowing which ones actually matter and why.

Strict-Transport-Security is the one I'd add first. It tells browsers to only ever connect to your site over HTTPS, even if someone types http:// or follows an old link. Without it, there's a class of attack on public WiFi where someone can intercept the initial unencrypted request before your site redirects to HTTPS. One header, five minutes to add, never think about it again.

For nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

X-Content-Type-Options: nosniff is the boring one that everyone should have. Browsers sometimes try to guess what type of file they've been served — a behaviour called MIME sniffing — which can be exploited if your site accepts file uploads. Setting this header tells the browser to just trust what the server says the file is. It's one line and the risk of not having it only goes up if you let users upload things.

X-Frame-Options prevents your pages from being embedded in iframes on other domains. The attack this protects against is clickjacking — your login page loaded invisibly inside someone else's site, with fake UI overlaid to trick users into clicking things they didn't mean to. DENY is the safest setting. If you need to allow specific origins, use the newer frame-ancestors directive in your Content Security Policy instead, which gives you more control.

Referrer-Policy is one most people skip because it sounds unimportant. When a user clicks a link from your site to another site, the browser sends a Referer header containing the full URL they came from. If your URLs contain anything sensitive — user IDs, session tokens, internal paths — those are being leaked to every external site your users navigate to. strict-origin-when-cross-origin is a sensible default that sends the origin but drops the path for cross-site requests.

Content Security Policy is the powerful one and also the annoying one. It lets you define exactly which scripts, styles, images and other resources are allowed to load on your page. Done properly, it stops XSS attacks even if an attacker manages to inject content — they still can't run arbitrary scripts because those scripts aren't on your allowlist.

The catch is that if you use third-party scripts (analytics, chat widgets, fonts, anything), you need to explicitly allow them, which turns into a bit of a project the first time. The way to approach it without breaking your site is to start in report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'; ...

This logs violations without blocking anything. You can see exactly what would break, adjust the policy, then switch to enforcing it once you're confident.

Beyond HTTP headers, the email-related DNS records are just as important and often completely missed. SPF and DMARC together control whether other mail servers will accept email claiming to be from your domain. Without them, anyone can send phishing emails that appear to come from you. Your bank, your customers, anyone. The fix is adding a few DNS records — your email provider (Google Workspace, Postmark, whoever) will give you the exact values to add.

The headers themselves take an afternoon to add. CSP takes longer if you have a lot of third-party dependencies, but you can ship the others immediately and tackle CSP properly as a separate piece of work.

If you want to see where your site currently stands, I built SecURL for exactly this — paste a URL and get a graded report with everything ranked by priority. Free, no account needed.

DEV Community: SecURL

I built a security scanner, never shipped it, and finally finished the job

What are HTTP security headers — and which ones does your site actually need?