CERTHIX / Application security

Protect the records. Control who can act.

Application security

How access and records are protected

The production authentication integration uses Microsoft Entra ID. Certhix validates the identity token before accepting an authenticated request.
The browser receives an encrypted, HttpOnly session cookie. Identity tokens remain behind the application’s server boundary.
Your Entra policies govern requirements such as multi-factor authentication. Signing in establishes identity; it does not grant unrestricted access to Certhix records.

Stored organisation memberships and permission grants determine which records a person can see and which actions they can perform.
Access is checked at the relevant school or site. Selecting a different organisation in the browser cannot grant access to it.
Viewing, editing, reviewing and verifying are separate permissions where the workflow requires them. The API checks authority again when a request is submitted.

PostgreSQL row-level security adds a database boundary around tenant-owned records, alongside the application’s access checks.
The application database account cannot bypass row-level security and does not own the tables. Schema changes use a separate migration role.
A database operation without the required tenant context is refused. Relationships between records also carry the organisation identifier.

The upload design authorises one storage object for a short period, with create-only permission over HTTPS. It does not grant access to a whole storage container.
File upload and malware clearance are different states. The evidence workflow uses trusted scan results rather than accepting a browser’s claim that a file is safe.
The Azure scanning integration requires Defender for Storage and trusted event delivery to be configured in the deployment. It is not a protection that can be assumed from uploading a file alone.

Filed inspection answers are protected from ordinary edits. Corrections follow a review cycle so the original submission remains distinguishable from the correction.
Material business actions have a durable audit trail. Failed sign-ins and denied requests belong in security logging, rather than being mistaken for completed business actions.
Revision checks prevent one person’s stale update from silently overwriting another person’s work. Incident narratives are excluded from audit metadata.

Tenant isolation, authorisation and record lifecycle checks are implemented in the application. Production network restrictions, backup policies, monitoring and storage scanning must also be configured and tested.
A cloud provider’s security controls do not by themselves establish the security of an application deployment. Access, configuration and recovery procedures need to work together.
This page describes technical controls; it does not assert ISO certification, an independent penetration-test result or a production service-level guarantee.

Illustrative workflows

The server checks membership and permitted scope for the selected school.
Queries run with the organisation context; a broader browser selection cannot broaden the underlying permission.
The leader receives only the records allowed by those checks.

The first person saves against the current record revision.
The second person’s outdated revision is rejected rather than overwriting the first change.
The team can reload the current record and make an informed update.