Legal
Security
Last updated
Every control below is described specifically enough for a security reviewer to verify it, and the section on current limitations states plainly what is not yet in place. This page is written to be used as evidence in a vendor assessment rather than read as marketing. The coordinated disclosure process is at the end; we do not treat a good-faith report as an attack.
Transport and browser hardening
Every request is served over HTTPS with TLS, and HTTP Strict Transport Security is set for a year including subdomains, so a browser that has visited once will refuse to downgrade. Responses carry X-Content-Type-Options: nosniff, X-Frame-Options: DENY to block clickjacking, and Referrer-Policy: strict-origin-when-cross-origin so a URL you were reading is not leaked in full to a site you click through to.
Passwords and sign-in
Passwords are stored as PBKDF2-HMAC-SHA256 hashes with a per-password random salt and a high iteration count. We never store, log or transmit a password in readable form, and there is no path by which we could show you your own password — if you lose it, it is reset, not recovered. Hash comparison is constant-time, so timing does not leak whether a password was close.
Failed logins are throttled to blunt credential stuffing and brute force. Where your organization uses Google Sign-In, we never receive a password at all, and the sign-in round trip is bound by a single-use state value that makes a cross-site request forgery on the callback fail.
Sessions and API keys
A session is an HMAC-signed token carrying only an account identifier and an expiry, set as a cookie that is HttpOnly (page scripts cannot read it), Secure (never sent over plain HTTP) and SameSite=Lax (not attached to cross-site requests). Because it is signed, a tampered or hand-crafted session is rejected rather than trusted; because it carries an expiry, a stolen one stops working.
API keys are stored as SHA-256 digests, so the database does not contain a usable key even to us. A key is shown once, at issue. It is scoped to the territory your plan covers, and it can be revoked and reissued immediately — email admin@infinidatum.net and we will rotate it.
Payments
Card data never touches our systems. Checkout is hosted by Stripe, a PCI-DSS Level 1 service provider, and we receive only the confirmation that a payment completed. Stripe webhooks are authenticated by verifying the signature on every delivery and rejecting anything outside a narrow timestamp window, so a captured-and-replayed notification cannot grant an entitlement. Entitlement changes are recorded append-only and keyed on the event identifier, which makes a duplicate delivery a no-op rather than a double grant.
Data handling and access control
Application data is held in managed PostgreSQL with encryption at rest and encrypted connections. Production access is restricted to personnel who operate the service, uses credentials separate from every other environment, and secrets are held in the platform’s encrypted environment store rather than in the repository.
The data model helps here more than any control does: the Service holds no consumer financial data and no member-level records. It analyzes institutions. The most sensitive thing in the database is a subscriber’s name, email and plan — which is a deliberately small blast radius, and the reason the Terms forbid you from sending us anything more.
Current limitations
Stated explicitly, because a security page that lists only strengths is not usable as evidence. CUSignals does not currently hold a SOC 2 Type II report or an ISO 27001 certificate, and has not commissioned a third-party penetration test. The login throttle is per-instance rather than a distributed edge rate limiter, which reduces its effectiveness under a multi-instance deployment. There is no bug bounty program; the coordinated disclosure process below is the reporting channel. If your procurement process requires any of these, raise it with us before you contract rather than after — we would rather lose the deal than pass an assessment on an implication.
Reporting a vulnerability
If you believe you have found a security issue, email admin@infinidatum.net with “Security disclosure” in the subject line. Include what you found, how to reproduce it, and what you think the impact is. We acknowledge reports within two business days and will keep you updated until it is closed.
Our commitments to a good-faith researcher:
- we will not pursue legal action or ask a third party to;
- we will credit you when we publish a fix, if you would like to be credited; and
- we will confirm when the issue is resolved rather than letting the thread go quiet.
What we ask in return, so that testing does not become an incident:
- do not access, modify or exfiltrate data belonging to anyone but yourself — use a test account, and stop at proof of concept;
- no denial of service, no load or stress testing, no spam, and no social engineering of our people or our providers;
- give us a reasonable window to fix the issue before you publish, and tell us if you plan to.
Incident response
No system is perfectly secure and we do not claim otherwise. If a breach affects personal information we hold, we notify affected users and the applicable regulators on the timeline set out in section 8 of the Privacy Policy. Questions about any of this go to admin@infinidatum.net.