Rezidomestics · Moby

Security and vulnerability disclosure

Last updated 6 August 2026

Reporting a vulnerability

Email security@moby.living. Tell us what you found, how to reproduce it, and what you think an attacker could do with it. You do not need to have a proof-of-concept exploit, and you do not need to know how serious it is — that is our job.

• We acknowledge within 2 working days and give you an assessment within 10 working days.
• We will tell you when it is fixed, and we will credit you if you want to be credited.
• We do not run a paid bounty programme, and we will say so honestly rather than leave you hoping.

Testing we welcome

If you act in good faith under this policy, we will not pursue or support legal action against you, and we will say so to anyone who asks. Please:

• Use only your own accounts and your own data. If you reach someone else's data, stop, and tell us what you saw so we can measure the exposure.
• Give us reasonable time to fix an issue before telling anyone else about it.
• Do not degrade the service for others — no denial-of-service testing, no automated scanning heavy enough to affect availability, no spam or phishing of our staff or customers, and no physical or social-engineering attacks.
• Do not alter or delete data that is not yours.

How we protect the platform

Access

• Two-factor authentication is available on every account type and is required for administrators of the platform itself.
• Sign-in attempts are rate-limited per account and per address, and every sign-in, failed sign-in and permission change is written to an append-only audit trail.
• Access to customer data is scoped by organisation and by role. A signed-in user cannot address another organisation's records, and that boundary is asserted by automated tests, not by convention.

Data

• All traffic is served over HTTPS with HSTS; the session cookie will not travel over plaintext at all.
• Stored third-party credentials and two-factor secrets are encrypted at the application layer before they reach the database.
• Payment card details are handled by Stripe and never reach our systems.
• Error diagnostics are scrubbed before they leave our infrastructure: request bodies, query strings and credential headers are removed, and the scrubber is written to discard the whole event if it cannot complete.

Build and change

• Every change runs an automated test suite, a dependency vulnerability audit, a secret scan and static analysis before it can be deployed.
• Dependency updates are raised automatically and security updates are grouped so they are not lost behind routine ones.
• Production, staging and development are separate environments with separate credentials, and the application refuses to start with production payment credentials outside production.

Availability and monitoring

• Errors are reported to a monitoring service in real time and tagged by component.
• Both services expose health endpoints that verify the database and cache, not just that a process is alive.
• The database is backed up continuously by our hosting provider.

If something goes wrong

We maintain an incident procedure covering detection, containment, assessment and notification. Where a personal data breach is likely to result in a risk to individuals we notify the Information Commissioner's Office within 72 hours of becoming aware of it, and we notify affected organisations without undue delay so that they can meet their own obligations to the people they serve.