Security

1. Current security model

The hosted service currently uses:

• 256-bit random capability tokens stored as cryptographic hashes;
• short-lived access capabilities with rolling rotation and separate long-lived refresh capabilities;
• read, write, name, version, expiry, and one-use attenuation controls;
• optional compound, TOTP, and passkey authentication profiles;
• header-first credentials, with credential-bearing query strings rejected by default;
• TLS in transit, private AWS S3 storage, server-side encryption at rest, and enforced encrypted S3 transport;
• optional client-side AES-256-GCM encryption;
• request, byte, storage, upload, and creation limits;
• a private static-asset allowlist, browser security headers, and restricted write CORS;
• tamper-evident per-box audit chaining; and
• a Cloudflare edge boundary with a secret-protected AWS origin.

Important limits remain. Account keys are bearer credentials, passkey registration attestation is not validated, content is not scanned, the deployment is small, backup and restore are not guaranteed, and no control can protect a capability copied from an endpoint you do not control.

2. How to report a vulnerability

Send a concise report to svc@anphase.co.nz with:

• the affected host, endpoint, feature, or client;
• the security impact and who could be affected;
• reproducible steps using a box and credentials you control;
• the smallest useful request and response excerpts, with secrets removed;
• any preconditions, timing, browser, operating system, or client details; and
• your preferred name, contact route, and disclosure expectations.

If sensitive material is needed after triage, we will agree on an appropriate transfer method. Do not create an svc.nz box containing the vulnerability report unless specifically asked, because sharing the reporting capability would become part of the problem.

3. Good-faith safe harbour

If you make a genuine effort to follow this policy, test only as necessary to demonstrate the issue, avoid harm, stop when you encounter another person’s data, and report promptly, Anphase Ltd will treat the work as authorised security research and does not intend to initiate legal action solely because of an accidental, good-faith policy violation.

This statement does not authorise breaches of other people’s systems, does not waive third-party rights, and cannot bind law enforcement or another organisation. Deliberate harm, extortion, privacy invasion, persistence after a stop request, or use of a vulnerability for personal gain is not good-faith research.

4. Research rules

When testing:

• use only boxes, accounts, capabilities, and content you created or have explicit permission to test;
• do not access, copy, alter, retain, or disclose another user’s content or credentials;
• do not perform denial-of-service testing, load testing, spam, social engineering, phishing, physical intrusion, or attacks on staff or suppliers;
• do not plant malware, create persistent access, or pivot into AWS, Cloudflare, email, DNS, or other third-party infrastructure;
• keep automation slow and bounded, and honour rate limits;
• collect the minimum evidence needed and delete it safely after resolution; and
• stop and report immediately if testing risks safety, availability, privacy, or data integrity.

Ask before doing anything that might fall outside these boundaries. A lack of immediate response does not expand authorisation.

5. Scope and useful findings

In scope are the hosted svc.nz web and API surfaces, the official browser tools and downloadable svcbox client when obtained from svc.nz, and security failures in capability scope, rotation, expiry, second factors, encryption transport, CORS, static isolation, quotas, or origin protection.

Especially useful findings include unauthorised cross-box access, capability disclosure, authentication bypass, persistent cross-site scripting, request smuggling with security impact, path traversal, server-side request forgery, remote code execution, origin bypass, or cryptographic misuse with a practical exploit.

Generally not eligible for priority are missing best-practice headers without an exploit, self-XSS, rate-limit observations without a demonstrated bypass, clickjacking already blocked by headers, leaked credentials from systems not controlled by Anphase Ltd, hypothetical attacks without a practical path, or findings that require the victim to disclose a capability intentionally.

6. What to expect

This is a single-operator private trial. There is no guaranteed acknowledgement or remediation deadline and no paid bug bounty. We will nevertheless try to acknowledge credible reports, reproduce the issue, assess severity, keep the reporter informed at sensible milestones, and say when the issue is resolved or accepted as a known risk.

We may ask you to pause testing, narrow a proof, delete data, or delay disclosure while a fix is prepared. Reports are prioritised by demonstrated impact, exploitability, affected users, and whether credentials or content are currently exposed.

7. Coordinated disclosure

Please give us a reasonable opportunity to investigate and fix a confirmed vulnerability before publishing technical details. We will not ask for indefinite silence. A disclosure date should reflect severity, active exploitation, fix complexity, and risk to users.

We are happy to credit useful reports if you want credit. We will not publish your identity or report details without permission unless required by law. Do not disclose live secrets, personal information, or details that would make an unresolved vulnerability easier to exploit.

8. Security guidance for users

Keep refresh capabilities offline where practical. Send access capabilities in the Authorization header, adopt cap_next, use narrow or time-limited caps for sharing, rotate on exposure, and keep encryption keys separate from capabilities and ciphertext. Clear the console’s local storage after using a shared browser.

Report content misuse through the Abuse Process. If you believe your capability leaked, invalidate or delete access first if you can, then contact us without placing the secret in email.