Security and Privacy

1Where data is processed

• Server functions (scan, API, MCP server, account, payment): Vercel, Frankfurt region (fra1). Set in vercel.json for all functions of the project.
• Database and sign-in: Supabase, Frankfurt region.
• Static files such as HTML, CSS and images are served by Vercel from the nearest location of its global network. They contain no data about you.
• Payments: Stripe. The contracting entity in the EU is Stripe Payments Europe, Limited in Ireland.
• Emails: Resend. Account data is stored there in the USA.

The legal basis for transfers to third countries is listed per service in the table under Service providers.

2What we store and what we never store

Never stored

• Full values of keys we find. If the scan finds a pattern that looks like a key, it names the type and where it was found. The report and the history contain only a shortened form, the beginning and the last characters, for example sk_live_…9f2A, and for database URLs the user and host without the password. We never show, store or use the full value.
• Your API keys in plain text. We store only the SHA-256 hash and the beginning of the key so you can recognise it. You see the full key once, when you create it.
• Card and bank details. You enter them directly with Stripe. They never reach our servers.
• Data for analytics or advertising. We embed no tracking services and set no advertising cookies.

Without an account

• We use the address you enter only for the scan. We store neither the address nor the result.
• For the limit of 20 scans per hour we count requests per IP address. The counter lives only in memory and expires after one hour.

With an account

• Email address for sign-in and notifications
• History: domain, grade, score, report, time and whether the scan came from the website, the API, MCP or monitoring
• Monitored sites with their last grade and last check time
• API keys as a hash, with name, prefix, last use and revocation date
• Audit orders and purchased single reports (domain, purchase email, private link and the report as of the scan)
• Plan and customer number at Stripe

Exactly what we process about you and for how long is described in the privacy policy.

3What the scan does on the site it checks

The scan reads only what a browser loads on a visit: response headers, the HTML, the JavaScript files and stylesheets from the same website including lazy-loaded parts and configuration files the code fetches itself, each with a size and time limit. In addition it performs a TLS handshake for the certificate, reads the file /.well-known/security.txt and public DNS records (such as SPF, DMARC, CAA, DNSSEC).

It does not try out paths, scan ports, send attack payloads or sign in anywhere. It never uses keys it finds. Software versions are matched against public databases, never against the site itself. The full list is under How we scan.

4Service providers (subprocessors)

These services process personal data on our behalf. The details come from the linked agreements and pages of each provider.

Stripe processes some data as an independent controller, for example for fraud prevention and to meet legal obligations. This is stated in Stripe's DPA.

Public data sources

We query these sources for matching. They receive no data about you and are not processors.

5Technical measures

The Hullwise code implements these measures:

• Protection against misuse of the scan (SSRF). The scan only fetches public addresses. Private networks, loopback, link-local and therefore cloud metadata addresses are blocked, including IPv4 addresses wrapped in IPv6. The check runs again on every connection so a name cannot switch to an internal address between check and fetch. Redirects are followed manually, every hop is checked, and the scan stops after five. Only http and https are allowed.
• HTTPS and HSTS. Hullwise runs encrypted only. The Strict-Transport-Security header applies for two years, including subdomains, with preload.
• Content Security Policy. Scripts, styles and connections only from our own domain, no embedding in other sites (frame-ancestors 'none'), forms only to Hullwise and Stripe. Inline scripts are currently allowed because Next.js needs them. Also X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.
• Signed cookies. Our own cookies for unlocks are signed with HMAC-SHA256 and compared in constant time. They are HttpOnly, Secure and SameSite=Lax.
• API keys as a hash. Keys are generated from 24 random bytes. The database holds only the SHA-256 hash. Revoked keys are rejected on every request.
• Row level security in the database. Row Level Security is enabled on all tables. Signed-in users can read only their own rows. Writes happen on the server only.
• No use of keys we find. The scan never tries credentials it finds and does not store their full values.
• Limits. Requests are limited per hour, per IP address or per account.

Hullwise holds no certification of its own, such as ISO 27001 or SOC 2. This page describes what the code does.

6Report a vulnerability

If you have found a vulnerability in Hullwise, write to us confidentially. How to do that and what is in scope is described under Report a vulnerability in Hullwise.

7Data Processing Agreement

If we process personal data on behalf of your company, for example accounts of your staff or reports on your systems, we conclude a data processing agreement under Art. 28 GDPR. You can read and print our Data Processing Agreement template and send it back to us completed.

8Questions

We answer questions from your procurement, data protection or IT team at cem@cdcapital-group.com.