Vistralio External Security Test

Date: 2026-04-14
Target build: 0.1.0 (Beta) Build 20260414.3
Test style: black-box external testing from the host, focused on publicly reachable HTTP surfaces and authentication boundaries

Scope

This test was performed as an external-style assessment rather than an internal code review. It focused on:

• publicly reachable HTTP entry points
• anonymous route behavior
• authentication and permission boundaries
• token misuse checks
• obvious information disclosure
• basic response/header observations

The test was intentionally non-destructive. It did not include:

• brute force attempts
• denial-of-service testing
• state-changing destructive requests
• data deletion
• exploit chaining

Exposed surface observed

Network listeners confirmed during the test:

• :80 exposed publicly via nginx
• :8000 bound to 127.0.0.1 only
• :8100 bound to 127.0.0.1 only

This means the API and license server are not directly exposed on public interfaces and are intended to be reached only through nginx.

Requests tested

Public shell and metadata routes:

• GET /
• GET /api/
• GET /api/health
• GET /api/branding
• GET /license-server

Protected application/API routes:

• GET /api/catalog
• GET /api/system/metrics
• GET /api/activity
• GET /api/settings
• GET /api/streams/1/snapshot
• GET /api/streams/1/snapshot?token=bogus
• GET /api/streams/1/detections?token=bogus

Protected license-server routes:

• GET /license-server/api/stats
• GET /license-server/api/licenses
• GET /license-server/api/customers
• GET /license-server/api/catalog
• GET /license-server/api/me

Authentication flow checks:

• POST /api/auth/login with invalid credentials

Findings

Low: baseline security headers missing

Observed on:

• GET /
• GET /api/
• GET /license-server/
• GET /api/health
• GET /api/branding

Headers not present in the tested responses:

• Content-Security-Policy
• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy
• Strict-Transport-Security

Impact:

• This is a hardening gap rather than a confirmed exploit.
• It increases exposure to clickjacking, content-type confusion, and general browser-side risk if the deployment is later extended or proxied in a less controlled way.

Recommendation:

• add a standard hardened header set at the nginx layer
• add HSTS only when HTTPS is enforced consistently

Informational: public deployment fingerprinting

Observed:

• GET /api/health returns the exact build string
• GET /api/branding returns login-shell branding details

Impact:

• This appears intentional for the login experience and support tooling.
• It does disclose versioning and environment styling details to anonymous users.

Recommendation:

• acceptable if desired operationally
• if you want less public fingerprinting, reduce build detail in the public health payload

Informational: /api/ explorer shell is anonymously reachable

Observed:

• GET /api/ returned the explorer HTML shell
• the underlying data route GET /api/catalog correctly returned 401 Not authenticated

Impact:

• No API data exposure or permission bypass was confirmed.
• This is minor surface disclosure because the client-side shell is visible before auth.

Recommendation:

• optional: require authentication before serving the /api/ HTML shell itself

Checks that failed closed

These behaved correctly during testing:

• GET /api/catalog returned 401
• GET /api/system/metrics returned 401
• GET /api/activity returned 401
• GET /api/settings returned 401
• GET /api/streams/1/snapshot returned 401
• invalid media-token probes on stream endpoints returned 401 Invalid token
• all tested /license-server/api/... routes returned 401
• invalid login credentials returned 401 Invalid credentials

Summary

No confirmed authentication bypass, permission bypass, or token misuse issue was found in the tested external scope.

The main outcomes from this external pass are:

• exposed network surface is limited appropriately
• protected API and license-server routes failed closed
• invalid token handling failed closed
• low-severity browser/security-header hardening gaps remain
• some public metadata exposure is intentional but should be treated as an operational choice

Suggested next action

If you want to continue hardening based on this report, the next practical step is:

1. add standard security headers at nginx
2. optionally require auth before serving the /api/ explorer shell
3. decide whether the public health endpoint should keep exposing the exact build string