Security & vulnerability disclosure

Technical security posture

Concrete defaults — what is in place today, not aspirations:

• Transport encryption. HTTPS-only across verif-ai.co.uk and all sub-domains; HSTS on the apex. Plain-HTTP requests are redirected, not served.
• Encryption at rest. Customer data and report history live in Neon Postgres (AWS eu-west-2, London). Storage encryption is AES-256, managed at the database layer.
• Hosting region. The application runs on Railway (EU); the database in AWS London (eu-west-2). Customer data does not leave UK / EU regions in normal operation. The one cross-region pathway is transactional email via Resend (UK–US data bridge), used only for account and report-share emails.
• Password storage. Passwords are salted and hashed via Werkzeug's default scheme (PBKDF2 / scrypt depending on environment). Plaintext passwords are never logged or stored.
• Session security. Session cookies are HttpOnly, SameSite=Strict, and Secure over HTTPS. CSRF tokens on all state-changing endpoints. Session secret rotated on credential changes.
• Content Security Policy. CSP headers with per-request nonces gate inline scripts; a Report-Only sister policy collects violation telemetry without breaking pages. Reports are filed via /api/csp-report and triaged.
• Payments. Card data never touches our servers — Stripe (PCI-DSS Level 1) handles the full payment surface via Checkout / Elements. We hold only the customer reference and last-4 / brand metadata Stripe returns.
• Admin access. Production database access is scoped to a small admin set with audited credentials. Admin endpoints in the app are gated by an is_admin flag on the user row.
• Companies House data. All filing data is fetched live from the official Companies House API. We don't scrape, we don't use third-party aggregators.

For the full picture of what data we collect, where it lives, and how long we keep it, see our privacy notice. Bug bounty / vulnerability disclosure terms continue below.

Scope

Services operated directly by Verif-AI are in scope:

• www.verif-ai.co.uk — the marketing site and sign-in
• app.verif-ai.co.uk — the authenticated dashboard and report generator
• api.verif-ai.co.uk — the programmatic API (including /api/v1/* endpoints)
• Email flows originating from @verif-ai.co.uk and @kaisark.ai

Third-party platforms we integrate with (Stripe, Resend, Companies House, Neon, Railway) are out of scope — please report findings on those services directly to the vendor.

How to report

Email support@verif-ai.co.uk with "Security disclosure" in the subject line. A high-quality report helps us triage quickly — please include:

• Affected target, feature, or URL (e.g. app.verif-ai.co.uk/api/v1/...)
• Description of the problem — what you found and why it matters
• Impact — what a real attacker could do with this
• Steps to reproduce — including any accounts, headers, or payloads needed
• Is this publicly known? Yes / No — and where, if yes

We don't have a PGP key yet. If you need encrypted transit, we'll happily provision one on request.

Our response commitment

If your report is in scope and follows this policy, we will:

• Acknowledge your report within 2 business days
• Triage and provide an initial assessment within 5 business days
• Fix critical issues within 30 days, or agree a public timeline with you if remediation is genuinely non-trivial
• Credit you publicly in our changelog once the fix is live — unless you prefer to remain anonymous

We don't currently offer a paid bounty. We recognise that's a choice, and we make up for it with a fast, respectful response and clear public credit. When we grow into a bounty programme, existing reporters will be given retrospective consideration.

Safe harbour

Verif-AI pledges not to initiate legal action against researchers who:

• Follow this disclosure policy in good faith
• Avoid privacy violations, data destruction, or service degradation
• Only interact with their own test accounts
• Do not exfiltrate, share, or retain personal data beyond what is needed to demonstrate the finding
• Give us a reasonable window to remediate before any public disclosure

If your research accidentally violates a provision of our Terms of Service, we will treat the research activity as authorised for the purposes of this policy.

Out of scope

The following are not eligible under this policy:

• Any vulnerability obtained by compromising a Verif-AI customer or employee account
• Missing best-practice, configuration, or policy suggestions without a working PoC (e.g. "you should add HSTS preload")
• Denial-of-service attacks, rate-limit probing, or volumetric testing
• Physical attacks on Verif-AI staff, offices, or data centres
• Social engineering of Verif-AI staff, contractors, vendors, or service providers
• Uploading, transmitting, or linking to malware
• Unsolicited bulk messaging (spam) or unauthorised outbound messages
• Clickjacking on pages with no sensitive actions
• Third-party vendor bugs unrelated to our integration
• Automated scanner output without a working PoC for a specific vulnerability
• Previously known vulnerable libraries without a working PoC
• SSL / TLS configuration reports already flagged by standard scanners without demonstrable impact

Guidelines for researchers

Please be considerate when testing:

• Test on your own account. Don't create an unnecessary number of accounts
• No unusual load. Keep request volumes reasonable — probe, don't hammer
• Stop when you've proven the vulnerability. Read-only access is enough to demonstrate most classes of bug
• No data exfiltration beyond the minimum needed to prove the finding. Redact or delete anything you do see
• Do not modify, delete, or exfiltrate other users' data under any circumstance
• Do not post publicly until we've researched, fixed, and (where customers are affected) notified them

Privacy incidents

If your finding relates to personal data (GDPR / UK Data Protection Act 2018) — for instance, data exposure, unauthorised access, or broken access controls on user data — mark the email "GDPR disclosure" instead. We treat privacy incidents as a separate workstream with its own response chain, and we have a regulatory 72-hour clock we need to respect.

Machine-readable (security.txt)

Per RFC 9116, a machine-readable copy of this contact is available at /.well-known/security.txt. Researcher tools should pick it up automatically.