Changelog

What has changed

Newest first. Each entry also explains how to use it through the API and MCP.

  1. Hullwise is now Hullwise

    The scan is now called Hullwise and runs at hullwise.co. Checks, prices, reports and accounts stay as they are. Purchased reports still open from your link, and the old address redirects to the new one.

    The MCP server now identifies as hullwise, the scanner as HullwiseScanner/1.0. Existing API keys keep working.

  2. Stricter CSP rating and a Supabase self-check

    The Content-Security-Policy now counts by its content, as in Google's CSP Evaluator and the Mozilla Observatory. If it doesn't govern scripts, allows 'unsafe-inline' without a nonce or hash, or allows scripts from any address, it earns 10 points instead of 25, plus a notice saying what is missing. Some sites get a lower grade as a result. The site hasn't changed; the rating has become more precise.

    No outside check can see whether Supabase tables are open. For that there is now a self-check: a read-only SQL query for the SQL Editor in your own project. It lists every table without Row Level Security and every policy that allows everyone everything. In the report, you copy it with one click.

    Under every finding in the report you can now report a false alarm. The email already contains the check ID and domain.

    New check ID header.csp.weak (severity info) with the field reasons: no_script, unsafe_inline, wildcard. The notice code.supabase.rls_check points to the self-check.

  3. Every finding with CWE, OWASP, ASVS and BSI

    Every check is now mapped to recognized standards: CWE from MITRE, OWASP Top 10:2025, OWASP ASVS 5.0.0 and the matching module of the German BSI IT-Grundschutz, and for data protection the legal basis. The mapping appears next to every finding in the report and the PDF, so you can place it in audits, for NIS2 or for auditors.

    We only reference IDs that exist in the respective version and check this automatically against the original sources with every change.

    New field standards on every visible finding in /api/v1/scan: cwe, owasp, asvs, bsi, law. Locked findings don't have it. In MCP results, the mapping follows every finding.

  4. Data protection check, domain and DNS, over 100 new key types

    A new data protection check covers common reasons for legal warnings in Germany: Google Fonts from Google's servers, tracking cookies and trackers before consent, embedded videos and maps, and missing links to the legal notice and privacy policy. It does not count toward the grade, which still measures the attack surface.

    Also new is the domain and DNS area: we detect addresses that point via CNAME to a service that no longer exists and can be taken over by strangers, and we check CAA, DNSSEC, security.txt, MTA-STS and SPF records with more than 10 DNS lookups.

    Key detection now also uses over 100 rules from the open-source project gitleaks, for example for Atlassian, Cloudflare, Datadog, Doppler, Heroku, Mailgun, Pulumi and Square. In our test run on over 100 real sites, this added no false alarms.

    The scan now reads up to 40 lazy-loaded code parts, including parts loaded only by other parts, for Next.js the code of every page from the build manifest, configuration files such as /config.json that the code fetches on startup, and Base64-encoded keys. In our test course with 13 typical leak locations, we now find all 13 instead of 7.

    New fields findings.privacy and findings.dns (missing in older reports). New check IDs: privacy.*, dns.*, email.spf.too_many_lookups, email.transport.unprotected. Additional providers appear under code.secret.service_token.

  5. Fewer false alarms, more key types

    The scan now detects 16 types of secret keys, new ones include Supabase account tokens, mail services such as Resend and Brevo, and access to Shopify admin, Notion, Airtable and Sentry. We also search the page source and embedded data, not only the JavaScript files.

    We only report third-party scripts without an integrity hash when a hash is actually possible there. We only check cookies that look like a session or sign-in. A Content Security Policy in the HTML now counts too. In our test run with over 100 real sites this removed about 60 false alarms.

    New notes cover Firebase rules, Supabase projects with the new key format and sites that do not redirect from http to https. Where we recognise the platform, the finding names the matching fix, for example for Vercel, Netlify or Lovable.

    New check IDs: code.secret.mail_api, code.secret.service_token, code.firebase.rules_check, https.no_redirect. Key findings carry found with location and shortened value.

  6. Vibe-coded apps: keys in JavaScript files

    Apps built with Lovable, Bolt, v0, Replit, Cursor, Claude Code or Codex often put their configuration into the JavaScript files every browser loads during a page visit. Keys that should never be public end up there too. The check now loads exactly these files: only the ones the page includes itself, only from the same domain, at most 10 files and 6 MB.

    In them, we look for 16 types of secret keys and credentials, such as the Supabase master key (service_role), keys for OpenAI, Anthropic and Stripe, AWS credentials and webhook URLs. We report type, count and where it was found, the value only shortened, for example sk_live_…9f2A. We never show or store the full value. Such a finding deducts 40 points.

    We also detect what an app runs on, such as Lovable, Vercel or Supabase. We still don't probe paths, and we never use keys we find.

    New check IDs such as code.secret.supabase_service_role, code.secret.openai, code.llm.browser_direct and code.supabase.rls_check. The report has two new fields: platforms lists the detected platforms, scripts the number of JavaScript files loaded. Findings about exposed keys carry critical: true.

  7. Full reports with Business

    Without a paid plan, the report shows the grade, the score and the number of findings. The two most urgent findings come in full with an explanation. The Business plan includes every finding with a fix guide.

    The shortening happens on our server, so locked findings never reach the browser or the client. This applies to the homepage, the API and the MCP server.

    Business costs €149 per month and checks up to 10 domains every week.

    With a free key, with the test key sc_test_demo and on the MCP server without a key, locked findings carry locked: true, without an id and without text. The locked field states the locked findings in hidden and all findings in total. With a key from an account on Business, it is absent.

  8. New website, API v1 and MCP server

    Hullwise has a new website. The check runs directly on the homepage without signing in, alongside a help center, developer docs and this page.

    New is the REST API v1, where a single call returns the full check. It requires a key. The key is free and allows 100 checks per hour. The MCP server also works without a key, with 20 checks per hour per IP address.

    GET /api/v1/scan returns the report as JSON. The MCP server offers the tools scan_website and list_checks for Claude, ChatGPT, Cursor, Codex and VS Code.

  9. Email protection and certificate in the check

    The check now tests whether someone can spoof email in the name of your domain. For that, we read the SPF and DMARC records from public DNS. If one is missing, SPF allows any sender or DMARC is set to monitoring only, the report says so.

    The certificate is checked too: whether it is valid, who issued it, when it expires and whether the connection still runs over TLS 1.0 or 1.1. Under 14 days to expiry is a warning; under 30 days, a notice.

    In the API and MCP, the report contains the new fields tls and email for this. The findings carry IDs such as email.dmarc.missing or tls.expiring.

  10. Following redirects safely

    If your site redirects, for example from the domain without www to the one with www, the check follows up to five hops. Before each hop, we verify that it does not point to an internal or private address.

    That way, a public site cannot steer our check to addresses that don't belong on the internet. The page where the redirect ends is the one that gets checked and graded.

    Through the API and MCP, the url field in the report states the hostname where the redirect ends. If a hop points to an internal address, the error blocked_host comes back.

  11. Stable check IDs

    Each of the 63 checks now has a stable ID, for example header.csp.missing or version.vulnerable. The ID does not change, even when we improve the text of a finding.

    This lets you count findings, react to specific ones in your pipeline or deliberately ignore them.

    The id field is on every finding, in the API response as well as in the structured data of scan_website.

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.