Everything an attacker checks first

We load your live site from the outside (no source, no login) and look for the same things a stranger with bad intent would find in the first five minutes. Here's every surface we cover on a free scan.

Secure connection

Your site is served over HTTPS, your certificate is valid and nowhere near expiry, and nothing on the page loads over an unsafe connection.

An expiring cert or a single asset loaded over HTTP is an opening to intercept or tamper with traffic. Users click through the warning, which is exactly what an attacker counts on.

  • certificate validity and expiry
  • HTTP→HTTPS redirect
  • HSTS
  • weak TLS versions and ciphers (TLS 1.0/1.1, DHE)
  • mixed content: insecure assets on a secure page
  • sign-in forms posting over plain HTTP

Domain safety

Your domain is set up so nobody can quietly issue a certificate in your name or bounce your visitors somewhere else.

A missing CAA record lets someone mint a valid certificate for your domain. A redirect that forwards wherever the URL says is a ready-made phishing lever. A fake site with real HTTPS is more dangerous than no HTTPS at all.

  • CAA records: who's allowed to issue certs for you
  • DNSSEC
  • www and non-www resolve consistently
  • redirect-chain length and loops
  • redirect-like parameters in the URL you scanned

Login & session safety

The cookies that keep users signed in are locked down so they can't be lifted and replayed.

A session cookie without HttpOnly can be stolen by any XSS; without Secure it leaks over HTTP; without SameSite it's exposed to CSRF. Steal the cookie and you skip the password entirely.

  • Secure flag on session cookies
  • HttpOnly flag on session cookies
  • SameSite on every cookie you set

Deeper checks on the sign-in flow itself are part of a verified scan. See Login page.

Browser protections

The headers that tell browsers how to defend your visitors are present and set correctly.

Missing headers are the difference between an XSS that's contained and one that runs unchecked. With no frame protection, your login page can be clickjacked inside someone else's site.

  • Content-Security-Policy
  • frame protection (X-Frame-Options / frame-ancestors)
  • X-Content-Type-Options
  • Referrer-Policy
  • Permissions-Policy

Exposed files & pages

The things that were never meant to be public aren't reachable.

A left-behind .env, an open /.git, an exposed backup, or a browsable directory is the fastest path from curious to inside. Attackers scan for these first because they're there more often than anyone admits.

  • exposed config and secrets files (.env, /.git, dump.sql-style backups)
  • directory listings left open
  • server version disclosure
  • framework disclosure via X-Powered-By
  • technology fingerprint disclosure
  • robots.txt hygiene
  • security.txt presence
  • sitemap hygiene
  • exposed admin and debug routesVerified scan

A verified scan widens the sensitive-file sweep considerably and probes for exposed admin/debug routes and API docs.

Speed basics

The basics that keep your site fast and cheap to serve.

Straight talk: this one isn't attacker-facing. We check it because we're already looking, and slow or oversized pages are worth knowing about.

  • page weight: oversized pages get flagged
  • server response time
  • caching headers

Login page

Verified scan

Point us at your sign-in page and we go deeper on the flow itself.

This runs only when you give us a login URL on a verified scan. It's not part of the free scan.

  • CSRF protection on the login formVerified scan
  • whether the page leaks which usernames existVerified scan
  • whether the login response is cachedVerified scan
  • password-field autocompleteVerified scan
  • where you land after signing inVerified scan

FAQs

We're new. Want to help?

Send us your work email, and we'll manually run a full security scan for you. We'll email you the link to your report, along with a polite ask about how we can improve.