Security & Privacy Practices

This page describes how Veloris (the “Platform”) protects your account and your data, and how to report a vulnerability. It is written at the level of design decisions and their reasoning; it deliberately omits configuration detail, version numbers and infrastructure specifics that would be more useful to an attacker than to you.

Everything below describes controls that are actually implemented. We hold no security certifications — not ISO 27001, not SOC 2, not HIPAA attestation — and we claim none. We would rather state that plainly than imply an audit that has not happened.

1. Authentication

• Passwords are hashed with bcrypt, a deliberately slow algorithm with a per-password salt. We never store your password and cannot recover it — a password reset sets a new one rather than retrieving the old.
• Session tokens live in httpOnly cookies, unreadable by JavaScript, so a cross-site scripting flaw cannot simply read your session out of browser storage. See the Cookie Policy.
• Access tokens are short-lived and refresh tokens rotate. Each refresh issues a new token and immediately invalidates the one used, so a captured refresh token has a narrow window of use.
• Sign-out is server-side. The session is revoked centrally, not merely forgotten by the browser — a copy of the cookie taken beforehand stops working too.
• A password reset invalidates every session everywhere, on the basis that anyone resetting a password may be responding to a compromise.
• Repeated failed sign-ins lock the account temporarily and send an alert to the registered address.
• Sign-in does not reveal whether an email is registered. Responses are equalised so that timing cannot be used to enumerate accounts.
• Password reset links are single-use and expire, so a link recovered from an inbox later cannot be replayed. Email verification links also expire.

Not yet available: multi-factor authentication. We would rather list it as a gap than let its absence go unmentioned.

2. Access control

• Every request is authorised server-side against the authenticated account. Hiding a control in the interface is never the mechanism.
• Study data — attempts, exams, conversations, flashcards, plans — is scoped to its owner.
• Administrative functions require the platform administrator role, checked on the server for every request.
• Credential documents are readable only by the account that submitted them and by administrators performing verification review.
• Unpublished and draft question content is not reachable by ordinary accounts, including via direct identifiers.
• AI features unlock only after credential approval and acknowledgement of the Medical Disclaimer.

3. Credential verification and uploads

Uploaded documents are the most sensitive data on the Platform, and are handled accordingly:

• Encrypted at rest — held encrypted whether stored on our own disk or in cloud object storage.
• Validated by content, not filename — a file’s actual signature must match an accepted type. Renaming an executable to .pdf does not get it accepted.
• Size-limited and streamed, so an oversized upload cannot be used to exhaust server memory.
• Malware scanned before storage, where a scanner is configured in the deployment.
• Reviewed by a human. Verification decisions are made by an administrator, not automatically, and each decision is recorded in the audit log.

Please upload only your own documents, and redact anything not needed to establish your identity and credentials. Never upload a document containing patient information.

4. Application security

• Rate limiting on authentication, AI and upload endpoints, constraining credential stuffing and automated abuse.
• Security headers on every response, including a Content-Security-Policy and clickjacking and MIME-sniffing protections.
• HTTPS in production, with session cookies marked Secure so they are never transmitted in clear text.
• Parameterised database access throughout, via an ORM, with user-supplied search input escaped so it cannot alter query semantics.
• Output escaping for user-supplied content wherever it is rendered, including in outbound email.
• Payment data never touches our servers. Card details go directly to Stripe; inbound webhooks are signature-verified before being acted on.
• Startup configuration checks refuse to run a production deployment with a weak or placeholder signing secret, or without HTTPS configured.

5. AI safety

A classifier refuses queries that appear to concern a real patient before they reach any model provider; content inside uploaded files and pasted text is treated as data rather than instructions; and blocked attempts are logged. Full detail, including the limits of these protections, is in the AI Usage Policy.

6. Audit logging

Security-relevant events are recorded with a timestamp, the account involved, and the originating IP address: sign-in, failed sign-in, lockout, password reset, credential submissions and decisions, disclaimer acknowledgements, administrative actions including role changes and account deletions, and AI queries refused by the safety classifier.

Audit entries are retained after an account is deleted, but anonymised — the reference to the account is removed and the event kept without it. A security history that disappears the moment an account is deleted is not a security history.

Where the Platform runs behind a proxy, forwarded client IPs are only trusted when the deployment is explicitly configured for it. Otherwise a client-supplied header could be used to forge a source address and poison the audit trail.

7. Data protection

• We collect what the service needs and no more — the full inventory is in the Privacy Policy.
• Chat history is optional and can be switched off at any time in Settings.
• Account deletion is self-service, immediate and permanent, and cascades through every table holding your data.
• Your name, date of birth, credential documents and billing details are never sent to AI providers.
• We do not train models on your content, and we do not sell personal data.

8. Responsible disclosure

If you believe you have found a vulnerability, we want to hear about it. Report it to security@veloris.health with enough detail to reproduce it — the affected endpoint or page, the steps, and the impact you believe it has.

Please do:

• report privately and give us a reasonable opportunity to fix the issue before disclosing it publicly;
• use only your own test account;
• stop as soon as you have confirmed a vulnerability exists.

Please do not:

• access, modify, delete or retain another user’s data — if you can reach it, that fact is the finding;
• run denial-of-service tests, spam, or high-volume automated scanning;
• use social engineering against our users or staff;
• demand payment in exchange for withholding a report.

What you can expect: acknowledgement within 5 working days; an assessment and indicative timeline within 10 working days; and an update when the issue is resolved. We will credit you if you would like to be credited.

We do not currently operate a paid bug bounty. If you act in good faith and within the guidelines above, we will not pursue legal action over your research.

9. Incident response

If a breach affecting personal data occurs, we will investigate, contain it, and notify the relevant supervisory authority and affected users as and when applicable law requires — telling you what happened, what data was involved, and what to do about it. No system is perfectly secure and we do not claim otherwise.

10. What you can do

• Use a long, unique password, ideally from a password manager.
• Never share your account. Beyond breaching the Acceptable Use Policy, it defeats every control on this page.
• Sign out on shared or public devices.
• Treat an unexpected lockout alert as a signal to reset your password.
• Keep patient data out of the Platform entirely.
• Report anything that looks wrong to security@veloris.health.