Security

All customer data is encrypted at rest with AES-256 on managed Google Cloud Platform infrastructure (MongoDB Atlas for application data, Google Cloud Storage for uploaded files and photos). Data in transit is protected by TLS, with HTTPS enforced at the edge.

Uploaded files are stored separately from the application database, scanned by Google Cloud Storage's built-in malware detection, and served through permission-checked endpoints rather than direct public URLs.

Passwords are hashed with bcrypt before storage — we never store or log the plaintext value. Account passwords must be at least 16 characters, and repeated failed login attempts trigger a progressive cooldown to slow down guessing attacks.

Sessions use HTTP-only cookies so that session tokens cannot be read by JavaScript in the browser, with the secure flag enabled in production. Mobile app sessions can be revoked, and biometric lock is supported on devices that offer it.

Every organisation's data is isolated at the query layer — members of one organisation cannot read or modify another organisation's projects, templates, or files. Within an organisation, role-based access control (Owner, Admin, Manager, User, Reviewer, Viewer) governs what each member can see and do.

Authorisation is enforced server-side on every request. Permission checks apply across a five-level hierarchy (system, organisation, project, resource, operation), and archived projects are read-only by default.

Authentication events, permission denials, and changes to projects and signoffs are recorded in an audit log with a unique request identifier. Personally identifying information in logs (such as email addresses) is hashed, and over fifty sensitive field patterns are automatically redacted before any log line is written.

Logs are retained for thirty days and stored in structured form so suspicious patterns can be reviewed quickly.

The application runs on Google Cloud Run, with HTTPS enforced and security headers (HSTS, X-Frame-Options, Content-Security-Policy and others) applied via Helmet. Cross-origin requests are restricted to a configured allowlist — we do not use wildcard CORS. Rate limiting is applied per endpoint and per authenticated user to limit brute force and abuse.

Resource limits cap the number of projects per organisation, nodes per project, and organisations a single member may own, so a compromised or misbehaving account cannot exhaust shared capacity.

We treat customer data as confidential and align our handling with the New Zealand Privacy Act 2020. Personal information is only used to operate the service, never sold, and shared with sub-processors only under confidentiality agreements. See our Privacy Policy for full detail on what we collect and how it is used.

If you believe you have found a security issue in idaWorks, please email admin@idaworks.co.nz with a description of the issue, steps to reproduce, and any relevant logs or screenshots. We ask that you give us a reasonable opportunity to investigate and fix the issue before any public disclosure, and that you do not access or modify data belonging to other users while testing.

We aim to acknowledge reports within two business days and will keep you informed of progress through to resolution.

Security is not a fixed checklist. We review our controls against current OWASP guidance on an ongoing basis, monitor dependencies for known vulnerabilities, and prioritise improvements as the product and threat landscape evolve.