Where your clients’ details live, and how I protect them.
Yven holds the details behind your clients' sites, so it should be the safest place for them. Here is what I do to protect them.
Encryption in transit
All traffic between your browser and my servers is encrypted using TLS 1.2 or higher. I enforce HTTPS on every route — there is no unencrypted fallback. Connections are automatically upgraded and HSTS is enabled so browsers remember to connect securely on future visits.
Encryption at rest
Your data is stored on encrypted volumes. Database backups are encrypted before leaving my infrastructure. Passwords are hashed with bcrypt and are never stored or logged in plaintext — not even I can read them.
Payment security
Yven does not store your credit card number, CVV, or full billing details. All payment data is handled directly by Stripe, who are PCI DSS Level 1 certified — the highest level of payment security certification available. I receive and store only a tokenised reference to your payment method.
Authentication
Accounts are protected by email-and-password authentication. Passwords must meet a minimum length requirement and are evaluated for common patterns at registration. I support email verification for new accounts. Session tokens are rotated on login and invalidated on logout. I log suspicious authentication events for review.
Tenant isolation
Yven is single-tenant-per-user. Every database query is automatically scoped to the authenticated user's account — a global scope enforced at the model layer that cannot be bypassed without an explicit and audited override. There is no shared data between accounts; your client list, work log, invoices, and registry are invisible to every other user of the service.
Infrastructure
Yven runs on DigitalOcean, a cloud provider with SOC 2 Type II certification. I run in a Canadian region where one is available. Server access is restricted to key-based SSH; password authentication is disabled. Firewall rules allow only the ports required for the service to function.
Backups
I take automated daily database backups. Backups are retained for at least seven days and stored separately from the primary infrastructure. I test restores periodically to verify the backups are usable. You can export your own data at any time from within the app.
Dependency management
I keep dependencies up to date and monitor for known vulnerabilities using automated tooling. Security patches are applied promptly. The application runs on a recent, actively maintained version of PHP and Laravel, both of which have dedicated security response teams.
What I don't store
Yven is designed to be a pointer, not a vault. I explicitly do not store client passwords, SSH keys, API secrets, or other credentials. The "Credential pointer" field on service records is intentionally a plain-text pointer to where a credential lives (for example, "1Password › Client vault") — not the credential itself. That limits what a breach could expose.
Responsible disclosure
If you discover a security vulnerability in Yven, please report it to me directly at [email protected] before disclosing it publicly. I will acknowledge your report within two business days, investigate promptly, and keep you informed of our progress. I ask for reasonable time to address the issue before any public disclosure. I do not pursue legal action against researchers who follow responsible disclosure principles.
Please include a description of the vulnerability, steps to reproduce it, and an assessment of potential impact. Screenshots, proof-of-concept code, or HTTP request/response excerpts are helpful where applicable.
Questions
Have a question about my security practices that isn't covered here? Get in touch — I'm happy to talk through the details.