Isolated security testing environment
A self-contained copy of the invoicing surface, seeded with invented hotel data, so your security team or a testing firm you retain can run a full test without touching production records. Operated by Apex Flow Technology Ltd.
Getting access
- Request an engagement key — one key per test, time-boxed to the dates you give us, revoked when the test closes.
- Exchange the key for a bearer token against a chosen tenant and role at
POST /api/public/pentest/session. - Test against the endpoints below. Reset the dataset whenever you need a clean state.
The full written test scope sets out ten test areas — input handling, authentication, tenant isolation, authorisation, webhook signing and replay, credential handling, business logic, transport and headers, rate limiting, and dependencies — with reproduction guidance, what counts as a finding, and the rules of engagement.
Request an engagement keyEndpoints
| Method | Path | Auth | What it is |
|---|---|---|---|
| POST | /api/public/pentest/session | x-pentest-key | Issues a signed bearer token for one synthetic tenant and role (viewer | finance). |
| GET | /api/public/pentest/invoices | Bearer token | Invoice list. Tenant comes from the token; query parameters cannot widen it. |
| GET | /api/public/pentest/invoices/{id} | Bearer token | Single invoice with guest and room. Cross-tenant ids return 404, not 403. |
| POST | /api/public/pentest/invoices/{id} | Bearer token (finance) | Body { "action": "void" }. Privilege check — viewer tokens must be refused. |
| POST | /api/public/pentest/webhook | HMAC-SHA256 | Late-charge ingest. Signature over `${timestamp}.${nonce}.${body}`, ±5 min skew, single-use nonce. |
| POST | /api/public/pentest/reset | x-pentest-key | Restores the synthetic dataset to its seed state at any point during the test. |
Synthetic tenants
Northgate Riverside Hotel
ten_alpha
3 rooms · 3 guests · 3 invoices
Cavendish Court Hotel
ten_beta
3 rooms · 2 guests · 2 invoices
Per-tenant webhook signing secrets are issued with the engagement key. Both tenants' secrets are provided deliberately, so cross-tenant signing can be tested.
In scope
- Authentication and token handling — forging, tampering, algorithm confusion, expiry bypass, replay of a captured bearer token.
- Tenant isolation — reaching Northgate data with a Cavendish token, by id, query parameter, header, body field or path traversal.
- Authorisation — performing the finance-only void with a viewer token, or through an unintended method or content type.
- Webhook security — signature forgery, body tampering after signing, nonce reuse, timestamp drift, cross-tenant signing.
- Input handling — injection, oversized payloads, type confusion, unicode and encoding tricks against the validation layer.
- Transport and headers — TLS configuration, security headers, cache behaviour, verbose errors, information disclosure.
- Rate limiting and resource exhaustion against the public endpoints.
Out of scope
- Denial-of-service volumetric flooding against the hosting platform.
- Social engineering, physical access, or testing of staff and third-party suppliers.
- The hosting provider's own control plane and any infrastructure outside the application.
- Production tenants and any real hotel data — this environment contains none.
Rules of engagement
Test only against the paths listed above, only within the agreed window, and send findings to the named contact before any disclosure. We respond to a critical finding within one working day and fix before any pilot property is connected.
Wider control documentation — architecture, CAIQ Lite, data processing terms and scan results — sits in the trust pack.