Security

Security audit: technical report

NEXIA Switch undergoes continuous black-box penetration testing that we run ourselves against an isolated lab replica —with no customer traffic and no routes to real carriers— so the exercise never risks service or billing. This document summarizes the methodology and the controls we verified. For security hygiene we do not publish addresses, hostnames, internal ports, private paths, exact thresholds, or any data that would give an attacker a map: only what was tested and how the system responded.

Methodology

  • Black-box, from the outside. The tool attacks as a third party with no privileged information would. We never log into the server to test, nor weaken any defense to "reach further".
  • Defense is the success criterion. When the system rejects, challenges, throttles or blocks an attempt, that counts as a validated control. A finding is opened only when the system fails to defend (leaks data, accepts an action it should deny, etc.).
  • Root cause and regression. Every finding is fixed in the source code —not with manual patches on the machine— and paired with a test that catches the problem if anyone tries to reintroduce it.
  • Coverage by surface. We audit the web panel/API and the voice signaling plane (SIP), the two exposed doors of the system.

Web surface — verified controls

CategoryValidated control
Transport / headersHSTS, content policy (CSP governed by the application), nosniff, anti-clickjacking and referrer/permissions policies are present.
File exposureThe served tree does not deliver dotfiles, schemas, backups or code artifacts.
SessionSession cookies carry protection attributes (HttpOnly, Secure, SameSite).
Authentication (CSRF)The anti-CSRF token is bound to the session and validated before credentials; forged tokens are rejected.
Authentication (errors)Errors are generic: no stack traces or internal details are leaked.
Authentication (enumeration)The response is uniform for valid and non-existent users: you cannot tell which accounts exist.
Authentication (brute force)Edge rate limiting cuts off login bursts.
Authorization (deny-by-default)Data endpoints require a valid session; without one, they are denied.
Customer isolationThe customer area is scoped to the identity of the session itself, not to a tamperable parameter: cross-customer access by identifier tampering is neutralized by design.
Billing integrityThe internal call-record ingestion channel is unreachable from the internet: forged records cannot be injected.
BypassNo access-control bypass via forged trusted headers or alternate HTTP methods.

SIP signaling surface — verified controls

CategoryValidated control
RegistrationRegistering an extension requires digest authentication: an anonymous attempt is challenged, never accepted.
Call setupCall signaling requires authentication; an attempt with no credentials does not progress.
Origin spoofingIdentity asserted by tamperable client headers is not trusted: spoofing a "trusted" origin is rejected.
Version leakThe signaling node does not reveal software or version in its responses.
Extension enumerationUniform response: you cannot infer which extensions exist.
Automated scansSignaling scans cut themselves off: after a bounded number of probes the edge stops responding and blocks the source.
How to read these tables. Each row is an attack that was attempted and that the system neutralized. The absence of exploitation detail is deliberate: we demonstrate the posture, we do not hand out a recipe.

Finding handling and disclosure

The cycle is finding → root-cause fix → regression test → publication, and we publish only after patching and verifying. We never describe a live vulnerability publicly. The patch log lists the holes already closed; the most recent was the exposure of the API schema document, fixed and with the fix baked into the installer so it never returns in future installs.

Continuous improvement

Coverage expands each iteration with new vectors and surfaces. A "no findings" result is not a permanent certificate: it is a snapshot that, for what has been audited so far, the system defended itself as it should. We keep testing it, and every closure is documented here.

Think you found a security problem? Write to support@nexianetworks.com. We practice responsible disclosure: we verify it, we fix it, and —once patched— you will see it published.
© 2026 NEXIA Networks · This wiki grows with every install: if something was missing, tell us and we add it.
On this page