Help

What we don’t check

What a check reads from the outside, what it never does, what it therefore can’t see and when an audit is worth it.

A check is like walking around a building from the street. We see open windows and doors, but we don’t go inside. Only the audit looks inside, and only with your permission.

What a check does

  • It loads your homepage once, the way any visitor does.
  • If the site redirects, it follows at most five hops. Before each one it makes sure the hop doesn’t point to an internal or private address.
  • It fetches the JavaScript files your homepage includes itself, the way every browser does when opening it. That is at most ten files at first, only from your domain, up to 2 MB per file and 6 MB in total.
  • In up to three short rounds it fetches at most 40 more files from your domain: further files the homepage includes, parts these files load when someone switches to a subpage (for Vite apps also parts that load further parts), and for Next.js the code of other pages listed in the build manifest. Every browser fetches those too as soon as someone clicks.
  • If the page's code fetches a configuration file from the same domain on startup, such as /config.json or /api/config, we read it too: at most four, only addresses written as fixed text in the code, read-only.
  • It reads the page's stylesheets from your domain (for the data protection check) and the file /.well-known/security.txt, which is meant for security reports.
  • It opens your homepage once over http://, the way a browser does when you type the address, and only checks whether it redirects to https.
  • While connecting, it reads your certificate and the version of the encryption.
  • In your domain’s public directory (DNS), it looks up records for email and domain protection: SPF, DMARC, MTA-STS, CAA, redirects (CNAME) and, via DNS-over-HTTPS at Cloudflare, DNSSEC. It doesn’t contact your server for this.
  • It compares detected software versions with the OSV.dev database and a small list of our own. That happens on our side, your site doesn’t notice.

We only read what comes back anyway: the response headers, the homepage HTML (the first 800 KB) and the content of the fetched JavaScript files. In those files we look for patterns of access keys. We don’t use anything we find.

What we never do

  • Probe hidden paths or fetch files such as .env
  • Load files your site doesn’t include itself, or read scripts from other domains
  • Look for open ports (port scan)
  • Submit forms or send attack code
  • Log in or use keys we find
  • Show or store the full values of keys we find
  • Check internal or private addresses

If we find something that looks like a key, we name the type and where it was found and show the value only shortened, for example sk_live_…9f2A, so you can match it at the provider. We never show, store or use the full value.

What we therefore don’t see

  • Subpages, login areas and everything behind a sign-in.
  • Scripts from other domains and code that is loaded only after a sign-in or beyond our limit of 40 lazy-loaded parts. For Next.js apps with the App Router, we only see other pages' code as far as the homepage names it.
  • Databases and storage, for example whether a table without access rules is open to the internet.
  • Access permissions, server settings and files nothing links to.
  • Your Git repository and the environment variables on the server.
  • Whether your server accepts old encryption versions alongside current ones.
  • The DKIM email signature, the SameSite cookie attribute and individual WordPress plugins.

In apps built with Lovable, Bolt and similar tools, the biggest risk is often the database. We find an exposed Supabase master key. Whether every table has access rules is something a check from the outside can’t see. The audit covers that. What you can check yourself is described in Access rules in Supabase.

Check, audit and pentest

CheckAudit
Permission neededNo, it only reads what is publicYes, you prove that you own the domain
What gets checkedYour homepage and its JavaScript files, from the outsideAlso databases, storage, access rules and areas behind the login
ResultIndications, “possibly affected”Confirmed findings with a fix
Who checksAutomated, in secondsBy hand, retest after your fix included
PriceFree€1,500 once per application

In a penetration test, or pentest, specialists deliberately try to break into your system. You agree on scope and rules in writing beforehand. It is worth it if you process sensitive data or your customers require such a test. Hullwise doesn’t offer pentests. If you’re not sure what you need, email us. We’ll also tell you if the audit isn’t enough.

You can book the audit under Pricing.

Still have questions? Email us.

Is your app
watertight?

Hullwise finds the leaks before someone else does: exposed keys, database credentials and outdated software. Every finding comes with steps to fix it.

https://

Click a finding to mark it as fixed.

See pricingHow a scan works

Ship fast. Stay hullwise.