How access is enforced

Every boundary is on the server

The console hides what a person may not do, but hiding is never the protection: every request is checked again on the server, and the screen only offers what the server already accepts.

• Organisations. Everything belongs to one organisation, and every lookup is scoped to it. Something of another organisation, asked for by any identifier, is answered not found, never "forbidden", so its existence is never confirmed.
• Workspaces. With restricted workspaces on, a workspace someone is not assigned to is not found for them either.
• Roles. Each route checks the person's role in that workspace. Reviewers read and review; only owners, managers and data collectors collect, checked on every web-form request.
• Phones. Every request from a phone re-checks its device key, its approval, its person and its organisation, so a revoked phone, a deactivated person or a suspended organisation is refused at once.
• Server administration. Every /admin address is not found for everyone but the server's maintainers, organisation owners included.

An automated sweep walks every route of the application for every kind of person (each role, a restricted or narrowed manager, an external client, a held, deactivated or suspended account, revoked keys and tokens), with another organisation's and another workspace's identifiers, malformed identifiers and bodies, and replayed and concurrent requests. It checks that nothing of the other side comes back, nothing of it changes, and nothing crashes. It runs with the test suite on every change.

Signing in

• Passwords are stored as scrypt hashes at a high cost, and checked in constant time; an unknown account costs the same as a wrong password and gets the same message.
• Lockouts: 8 failures per account and 30 per network address in 15 minutes, on every door (the sign-in page, Joripo Collect, ODK Collect, Forgot password and Server administration), counted in the database so a restart forgets nothing.
• Sessions end with the browser, after 2 hours unused, and 7 days after sign-in at most (14 days unused and 30 days at most with Keep me signed in). Signing out, a new password, a lower role or deactivation end every session of that person.
• Every form post carries a per-session security token (CSRF protection), checked on the server; a request with an API token needs none because a token can only read.
• The server's maintainers sign in with a password and a six-digit authenticator code, on a session of their own.

What the browser is told

Every response tells the browser not to guess file types, sends the referrer only to the same site, and lets only the server itself frame its pages; HTTPS responses add strict transport security. Every response to a signed-in request, and every API and device response, is marked not to be cached, so a shared computer's browser keeps no copy of respondent data.

What comes in

• Submission XML is parsed safely: a document with a DTD or entities, or malformed XML, is refused before anything is stored.
• A re-sent submission with different content never overwrites the stored one: the first copy stays authoritative, the other is kept beside it, and the event is recorded.
• Zip files are limited by the bytes actually decompressed, not what their header claims. Submissions are limited to 100 MB, and every other upload to 250 MB unless the server sets otherwise, enforced while the body arrives, so neither memory nor disk can be filled.
• Files people upload (attachments from anonymous respondents too, form media, plug-ins) are never served as a page: pictures, recordings and plain text open in the browser, everything else downloads, and none of it can run as script on the console's address.

Secrets

No secret belongs in Joripo's source code, and a test fails if one appears there. Passwords, keys and the maintainers' credentials live outside the code and outside the data folder.