Security Verification & Architecture Review
Enterprise technical evaluation resources covering isolation, integration security, resilience testing and data handling.
This document is maintained by Apex Flow Technology Ltd for technical reviewers, enterprise architects and security teams. It describes the controls currently implemented in the evaluation environment and the evidence available for independent assessment. It is not a third-party audit, certification or attestation.
- Tables scanned
- 40
- Tables passing
- 40
- Warnings
- 0
- Critical findings
- 0
Executed 2 August 2026 against the live database using the in-product validation routine, which checks every table in the application schema for row level security status, policy coverage and permissions wider than the policies allow. Results reflect that run only and are re-executed on each review cycle.
PDF · v1.1 · includes run details, timestamps, findings and reviewer resources.
Apex Flow uses PostgreSQL Row Level Security (RLS) as the primary tenant isolation boundary. Isolation is enforced by the database itself rather than by application code alone, so a query issued outside the intended tenant context returns no rows.
Tenant-scoped tables require explicit security policies. A table with RLS enabled and no policy is closed by default, and access is granted only through policies written for a named role and operation.
New database objects must ship with their security policies as part of the same migration process. Schema, policies and permissions are introduced in a single reviewed change rather than in separate steps.
- Row Level Security enabled on tenant-scoped tables
- Explicit access policies
- Controlled database permissions
- Tenant isolation validation
In addition to the database validation run above, the platform is subjected to an automated adversary simulation suite that reproduces the steps a human penetration tester would take against the multi-tenant isolation barriers. The suite runs on every change and a failure blocks the build.
- Attack simulations
- 63
- Passing
- 63
- Attack categories
- 5
- Vulnerabilities found
- 1
- Open findings
- 0
Executed 8 August 2026. 63 of 63 attack simulations passing.
Forged and replayed PMS webhooks
Signature, timestamp and nonce handling on the inbound PMS webhook path, exercised the way an attacker with a captured request would exercise it.
- Unsigned requests posted directly at the endpoint are refused
- Requests missing the signature, timestamp or nonce header are refused
- A signature minted with one tenant's secret does not authenticate against another tenant
- A body tampered with after signing (amount inflated in flight) is refused
- A captured, perfectly valid request cannot be replayed a second time
- Stale and future-dated timestamps (clock-skew abuse) are refused
- Malformed signatures - empty, odd-length, non-hex, truncated, oversized, padded - are refused without crashing
- Byte-length-mismatched signature prefixes are refused; the genuine signature is accepted as a control case
Tenant identifier manipulation
The per-tenant webhook path is attacked with hostile organisation identifiers to confirm the isolation boundary is established before any database access.
- Path traversal and encoded traversal identifiers are refused
- SQL injection, wildcard, null-byte and newline-injected identifiers are refused
- Empty, short, over-long and payload-appended identifiers are refused
- The identifier shape is validated before the database is touched
- The tenant secret is looked up from the URL identifier, never taken from the request body
- An unknown tenant is refused before any event is enqueued
- Persisted events are stamped with the URL tenant, not a client-controlled value
Privilege escalation through server functions
Static and behavioural audit of every server function that can reach the row-level-security-bypassing administrative client.
- Every server function reaching the administrative client is authenticated or explicitly allow-listed
- Allow-listed public modules cannot be pointed at another tenant by the caller
- The public demo module pins every administrative query to a hardcoded demo tenant
- The administrative client is never imported at module scope, so it cannot ship to the browser
- Privilege checks read roles from the dedicated roles table, never from a profile or client-supplied field
- No server function derives the acting user from request data instead of the verified context
- The authentication middleware verifies bearer tokens against the auth server rather than decoding locally
Open redirect on the post-authentication path
The post-login return parameter is attacked with the encoding tricks used to bounce a signed-in user to an attacker-controlled host.
- Encoded double slash, encoded backslash and triple slash are neutralised
- Tab, newline and carriage-return smuggled protocol-relative targets are neutralised
- Whitespace-padded, uppercase and credential-bearing schemes are neutralised
- Unicode fullwidth solidus and javascript: after a valid-looking prefix are neutralised
- Legitimate in-app deep links still resolve (control case)
- The authenticated gate always returns unauthenticated visitors to the sign-in route
Credential harvesting from the shipped bundle
Static analysis of the source tree confirming privileged credentials cannot reach a browser bundle or a log line.
- No service-role or secret key literal exists anywhere in the source tree
- The service-role key is read only from server-only modules
- No secret is exposed through a browser-visible environment variable
- Worker and webhook secrets are compared, never logged
Finding raised and remediated in this run
Raised 8 August 2026 - remediated 8 August 2026 - open findings: 0
One real defect was identified by the simulation: the post-authentication redirect guard could be bypassed with percent-encoded backslashes and smuggled control characters, allowing an off-site redirect after sign-in. This has been fixed. The guard was rewritten to reject control characters and to re-validate the percent-decoded form of the target, so both raw and encoded bypasses now fail closed. The fix was verified by re-running the full simulation suite, and every bypass case is retained as a permanent regression test so the defect cannot silently return. No other defects were raised; the remaining 62 simulations confirmed existing controls. There are no open findings from this run.
These results are self-assessed and produced by our own test suite. They are not a third-party penetration test, audit or certification.
Apex Flow is designed as an overlay architecture operating alongside existing hospitality systems. During evaluation it consumes event and folio data and produces its own output; it does not write back to, or take over functions of, the property management system.
- Read-only evaluation architecture
- Secure webhook validation
- Request authentication controls
- Trace ID based request observability
- No production system modification during evaluation
The following validation resources are executed against the evaluation environment and their outputs are available for review.
- k6 load testing
- High-volume transaction processing validation
- Latency benchmarking
- Duplicate event protection testing
- Failure injection testing
- Recovery workflow validation
The evaluation environment is designed so that a technical review can be completed without exposing production guest or payment data.
- Sandbox requests are not persisted
- Evaluation environments are isolated
- Controlled data access model
- No production PMS connection required for evaluation
Apex Flow follows a security-first development approach where database schema changes, access controls and tenant isolation policies are reviewed together. Security controls are treated as part of the deployment process rather than added after development.
Each database migration follows a fixed template — table definition, row level security, policies, indexes and permissions — and the automated validation routine is re-run afterwards so that any table left without matching policies and permissions is surfaced before it reaches an environment used for evaluation.
These resources are open to technical teams during evaluation and can be assessed independently, without a commercial commitment or a connection to a production system.