How CertiPOS protects the data, the money and the evidence

CertiPOS is built to the OWASP Application Security Verification Standard at level 2. The checklist with its named gaps is part of the documentation; a set of generated security tests runs on every build and probes every endpoint for cross-tenant access, leaked secrets, malformed input and open redirects.

Tenancy

Every server table carries the tenant and a row-level security policy created in the same migration. The application connects under a role for which the policies are forced, so no query can cross a company by accident or by injection.

Transport

• HTTPS with your own certificate or one the installer issues; every register pins the fingerprint from the enrolment QR; TLS can be required for every call.
• HTTP Strict Transport Security, security headers, a Content Security Policy that allows no external origin and uses a per-request nonce for scripts.
• Rate limits on sign-in and API calls per address; request body size limits; a signed webhook receiver with an SSRF guard.

Identity

• Devices enrol once with a code and receive an X.509 certificate from a per-tenant CA; tokens are short-lived and bound to the device; retired devices cannot return.
• Register users sign in with a PIN, card or badge under policies for length, history, expiry and lockout; the PIN hash is verified off the UI thread.
• Portal users sign in with a password, a time-based second step and recovery codes; another administrator can reset the second step.
• Session policies: idle lock and logout, single login with take-over, training mode, time clock.

Authorization and approvals

• Over 170 named rights with allow, deny or approval required, and thresholds where a value matters; roles with rank; the register shows a tile only when its own right is granted.
• Approvals by PIN, card or remotely from a manager’s phone; per action, per ticket or per session; performer and approver are always different people.
• Every override is journaled with the performer, the approver, the method, the reason, the value attempted and the value allowed; the server verifies the journal.

Evidence

• Ticket events are append-only; voids are marked; every ticket carries the register sequence and a hash chain.
• Configuration changes are stored as diffs; reads of sensitive data are audited; audit exports are CSV.

Secrets, logs, bundles

• SAP passwords and other secrets are protected with DPAPI or AES in a protected secrets file; configuration answers, audit rows and support bundles never contain a secret.
• Logs are structured and never contain PINs, tokens, card numbers or secrets.
• Backups are scheduled dumps with a tested restore; remote wipe of a device needs a second administrator through a device-signed door.