Security
Security policy and responsible disclosure
We sell security, so we publish ours. If you think you have found a vulnerability in Qorionix, read this first — it tells you where to send it, what we will do, and what we commit to not doing to you.
Where to send it
[email protected] with [SECURITY] in the subject.
We acknowledge valid reports within three business days. There is deliberately no form and no account required: during an incident affecting our own services, email is the channel that still works, and you should not have to trust a form on the host you are testing.
Machine-readable version: /.well-known/security.txt
Scope
What is covered
In scope
- qorionix.com, including www and every per-tenant subdomain of the product console
- Any subdomain we publicly list on that domain
- The product console and any API endpoint we advertise
- The support portal and the knowledge base
- Any public email address or intake form we operate
- The endpoint sensor packages we distribute, and their update path
Out of scope
- Third-party services and vendors we depend on. Report those to the vendor directly; tell us too if it affects you as our customer.
- Denial-of-service attacks, brute-force attempts, and anything that degrades availability for other users.
- Social engineering of employees or contractors.
- Physical attacks against offices, data centres or personnel.
- Automated scanning that produces meaningful load without prior written coordination.
- Reports consisting only of a scanner output with no demonstrated impact.
- Missing hardening headers with no demonstrated exploit path, and issues that require a fully compromised device or a browser the vendor no longer supports.
Reporting
What to include
- A clear description of the issue and its impact — what an attacker gains, not only what is technically wrong.
- Steps to reproduce: exact URLs, payloads, timestamps in UTC, and the account or tenant you used.
- Which user roles or classes of data are affected.
- Supporting evidence: screenshots, or proof-of-concept code with any credentials redacted.
- Whether you have disclosed it anywhere else, and whether you intend to.
Our remediation targets
- Critical
- Mitigation within 72 hours
- High
- Fix within 14 days
- Medium
- Fix within 30 days
- Low
- Scheduled on the normal release cadence
Safe harbour
If you follow this policy in good faith, we will not initiate legal action against you for your research, and we will say so in writing if you need us to.
In return, please do not:
- Access, modify or destroy data that is not yours
- Take more data than is necessary to demonstrate the issue
- Disclose publicly before we have had a reasonable chance to fix it — we will agree a coordinated date with you
- Target other Qorionix customers, their tenants, or our partners
What happens to your report
Every valid report is triaged by a named owner, entered into our tracking system with the target above, and peer-reviewed before it is closed. A root-cause analysis is written for every confirmed vulnerability and feeds back into code review, threat modelling and training.
We maintain an acknowledgements list for researchers who report valid issues, opt-in. A bug-bounty programme with monetary rewards launches with general availability.
If you are our customer and being attacked
This page is for reporting flaws in our software. If you believe an attack is in progress against your own organisation, that is a support matter and it is urgent: email us with the subject prefix [INCIDENT] and say so in the first line, and check service status in case the two are related.
Deliberate disclosures
Things we expose on purpose, and why
Some information has to be readable before anyone has signed in. Publishing which information, rather than leaving a researcher to discover it, is the point of this section — and it means a report about one of these is not a finding, it is a disagreement with a documented decision, which is a more useful conversation.
Whether an email domain is federated, and to which identity provider
GET /api/v1/federation/discover?email=… is unauthenticated. It has to be: home-realm discovery decides where to send your browser before you have signed in, so it cannot sit behind a credential. Given an address it returns whether that domain is federated and, if so, the provider’s display name, its type, the protocol, the organisation id and the sign-in URL to redirect to.
So an unauthenticated caller can learn that a domain belongs to a Qorionix customer and which IdP that customer federates with. We think that is an acceptable trade for working SSO, and we are not the only ones: Okta’s equivalent endpoint documents itself as “a public, unprotected interface that can be queried without supplying an SSWS token”, and returns the routed provider’s display name, type, internal id and a link to its SAML metadata. Our response is bounded to that same class and no wider.
What it does not do is tell you whether a person exists. [email protected] and [email protected] return byte-identical answers, because the lookup discards the local part and queries only the domain-claim tables — the user table is not reachable from that code path, and a test asserts it rather than a comment promising it. A malformed address and an unfederated domain also return the same answer, so the endpoint cannot be used to map which domains a customer has configured. It is rate-limited to 30 requests per minute per address.
Whether an account exists, on the password login form
It does not. A wrong password and an address with no account are the same response, and so is a deactivated account — which is why our own knowledge base tells administrators to diagnose a failed sign-in from the user record and the audit log rather than from the error message. Sign-in attempts are rate-limited and answer 429 once the limit is reached; that status is itself a signal that requests arrived, but it is not tied to whether the account is real.
Our tenant subdomains
Certificate transparency logs make every hostname we bind a certificate for public, permanently, and there is nothing any vendor can do about that. We would rather say so than have it read as an oversight: a tenant subdomain is not a secret and must not be treated as one, by us or by you. Nothing about a tenant is reachable from knowing its hostname without a credential scoped to that tenant.
Our own security posture
Encryption, access control, tenant isolation, personnel security, the three authentication bypasses we found in our own code and how we fixed them — all on the trust centre, with dates.