Security
How ODMOP is built to protect your organisation
These are controls that exist in the product today, and, further down, what we have not done. We describe them so you can judge them, not to reassure you.
Environments are separate
The Website, the Sandbox and Live are three separate deployments. The Sandbox and Live each have their own database, accounts, sessions, signing keys and e-mail identity. A Sandbox account, session or invitation does not work in Live, and Live refuses to start against a Sandbox database. Nothing inside the product moves you from one environment to the other.
Organisations are isolated from each other
Every request carries a signed, short-lived statement of which organisation and person it is for. The application checks it, and the database enforces it again with row-level security, so a mistake in one layer is not enough to read another organisation's data. Access is decided by roles on the server; hiding a button in the interface is never the control.
Signing in
- Passwords are stored with Argon2id, a slow, memory-hard hash. Sign-in attempts are rate-limited.
- Two-step verification with an authenticator app and recovery codes is available. Sensitive changes ask you to confirm your password again.
- Sessions are stored on the server, last at most seven days, can be listed and ended, and all end when a password is reset.
- Nobody can register themselves. Accounts are created through invitations that work once, are stored only as hashes and expire.
Requests and the browser
- Changing requests must carry a marker header and come from the application's own address, which blocks cross-site request forgery. Cross-origin access is not enabled.
- A strict Content Security Policy, HSTS and the other standard security headers are set. The application loads no third-party scripts.
- Sandbox and Live pages are marked so that search engines do not index them. This website sets no cookies at all.
Our own access
Setting up, extending, resetting or removing an organisation is done by named operators with their own separate access, not through the application. Every operator command must name the environment it targets, refuses to run against the wrong one, and asks for the organisation's name to be typed before anything destructive. Each one is written to the audit history.
Data in transit and at rest
Connections use HTTPS and the browser is told to require it. Encryption of stored data depends on the database and hosting service chosen for each environment; we will name them in your agreement before your organisation is activated.
A record of every change
Changes to people, roles, settings and access are written to an append-only audit history. Refused attempts are recorded too. Not even our operators can edit or delete entries. Operator actions, such as creating or extending an evaluation, are audited under the operator's name.
What we have not done yet
- ODMOP has not had an independent security audit or penetration test, and holds no security certification. We make no compliance claims.
- Backup and restore procedures are written but have not been exercised on production infrastructure, because none exists yet.
- Monitoring and an incident process for the live service are not yet in place. Evidence is recorded as a link or reference only; ODMOP stores no uploaded files, so there is no file scanning to describe.
Reporting a vulnerability
Write to security@afolaola.com (also listed in our security.txt). Describe what you found, how to reproduce it and what you expected. Please test only with your own accounts and synthetic data, do not access other people's data, and give us a reasonable time to fix a problem before you publish it. We do not yet run a bug-bounty programme.