How VitalFax protects the documents you put in it.
This page describes controls that exist in the product today. Where something is planned rather than built, it says so. Designed for HIPAA-regulated workflows.
Tenant isolation
The control everything else depends on
VitalFax holds documents belonging to unrelated organizations. Keeping them apart is not a feature, it is the premise.
Every record is bound to one organization
Each tenant-owned table carries an organization id with a foreign key. There is no row that belongs to nobody and no row shared between tenants.
The server decides which tenant you are
The active organization is read from the server-side session, never from a URL, a form field or a header. Changing an id in a request changes nothing.
Queries cannot forget the filter
All tenant data access goes through a scope object that owns the organization id and builds the WHERE clause itself. Forgetting it is not expressible.
Another tenant’s record looks like a missing one
A request for an id belonging to someone else returns "not found", not "forbidden". A different answer would confirm the record exists.
Storage is partitioned too
Object keys begin with the organization id, and the prefix is re-checked before any document is read, so a corrupted key cannot cross a boundary.
It is tested adversarially
The test suite attempts cross-tenant access with guessed ids, manipulated parameters and mismatched API keys, and asserts each attempt fails.
Controls
What is in place
Access
- Passwords are hashed with scrypt using OWASP-aligned parameters. They are never stored or logged in any recoverable form.
- Sessions are server-side. The browser holds a random token; the database holds only its keyed hash.
- Sessions have both an absolute lifetime and an idle timeout, and both are configurable per organization.
- Multi-factor authentication uses TOTP with single-use recovery codes.
- Changing a password ends every session on every device.
- Sign out everywhere is available to each user from their settings.
- Repeated failed sign-ins lock the account for a period and are recorded.
Data
- Transport is HTTPS. HSTS is set with a two-year max-age.
- Production object storage must be a managed service with encryption at rest; local disk is rejected outright in production configuration.
- Uploads are validated by magic bytes, not by the filename or the declared type. Active formats such as SVG are refused.
- Filenames are sanitized, and object keys are generated by VitalFax rather than derived from user input.
- Document retention is configurable per organization, and expired documents are surfaced for deletion rather than removed silently.
- Audit records are append-only: no code path updates or deletes them.
Operations
- Application logs are filtered before they are written. Names, numbers, email addresses, filenames and document contents are redacted by the logger itself.
- Notifications state that something arrived, never what it contains.
- Webhook payloads carry identifiers and status only; detail requires an authenticated API call.
- Inbound provider webhooks are signature-verified where the provider supports it, and de-duplicated by event id so a redelivery is never processed twice.
- Outbound webhook destinations are restricted to public HTTPS hosts; loopback, private and metadata addresses are refused.
- A health endpoint reports database, storage and provider status without exposing configuration.
Support access
VitalFax staff cannot browse your documents
There is no internal screen that lists customer documents. When support genuinely needs access, it is an event, not a default.
- Your organization must enable support access before any grant can be created.
- A grant requires a written reason of at least twenty characters.
- A grant expires automatically, with a maximum lifetime set by configuration.
- A grant can be narrowed to a single record.
- Granting, each individual use, and revocation are written to your audit log, not only to ours.
Being straight with you
What is not done yet
A security page that lists only strengths is not useful. These are the gaps as they stand.
No third-party audit
VitalFax has not completed SOC 2, HITRUST or any comparable assessment, and does not claim to have.
Production vendors not yet contracted
The fax provider, object storage, email and error tracking used in production require agreements and Business Associate Agreements that are not yet executed.
Rate limiting is per process
Abuse protection currently runs in-process, which is sufficient for a single instance. A multi-instance deployment needs a shared store first.
Penetration test not yet performed
Internal review has been done and is documented in the repository. An independent test has not been commissioned.
Reporting
Responsible disclosure
If you believe you have found a security issue in VitalFax, tell us and we will respond.
Email security@vitalfax.com with enough detail to reproduce the issue. We will acknowledge receipt, keep you updated while we investigate, and credit you if you would like us to. Please do not access or modify data that is not yours while testing.
Security contacts
- Security reports
- security@vitalfax.com
- Incidents
- security@vitalfax.com
- General support
- support@vitalfax.com
Deeper technical detail, including the tenancy model and the threat list we review against, is maintained in the repository documentation and available to customers under evaluation. Ask for it.