SECURITY
Blackbox Systems security.
Security documentation keeps three things separate: the posture of the public product surface, the coordinated process for reporting a suspected vulnerability, and the explicitly authorized, scoped practice of active security validation.
What this page covers
Security on this estate is three separable things kept separate: the posture of the public product surface you are reading now, the coordinated process for reporting a suspected vulnerability in it, and the explicitly authorized, scoped practice of active security validation performed under contract. Conflating them is itself a security failure, so each is documented on its own terms below.
Public product surface
The Blackbox public site is a deterministic static export served through Cloudflare Pages. There is no server runtime, no application database, and no authenticated session on this surface, which removes whole classes of risk by construction rather than by control. Security headers are declared statically through the published headers file, and a security.txt contact route is published under the well-known path so a researcher never has to guess where to send a report.
The headers, and what they are for
The declared headers constrain the browser rather than trust it: a content security policy limits where scripts, styles and connections may originate; strict transport security pins the connection to HTTPS; frame and content-type options close clickjacking and MIME-sniffing paths; and referrer and permissions policies limit what the page may leak or request. Because the surface is static, these are the primary controls, and they are reviewed as part of the export rather than configured on a mutable server after the fact.
Coordinated vulnerability disclosure
Suspected vulnerabilities can be reported to security@mediatorsolutions.io. A good report states what was observed, the exact conditions to reproduce it, and the impact, and does not include data collected from anyone other than the reporter. We acknowledge a report, confirm or reproduce it, and work the remediation; we ask reporters to allow reasonable time to fix before public discussion. Reporting a suspected issue is welcome — it does not, by itself, authorize active testing, access-control bypass, denial of service, social engineering, or the collection of unrelated data.
The line between reporting and testing
Observing something in the course of ordinary use and reporting it is disclosure. Probing, fuzzing, bypassing a control, or exercising a system to see what breaks is active testing, and active testing of any target requires authorization in advance. This distinction is not a formality: unauthorized testing of a system you do not own is a boundary we will not treat as research, however good the intent, because the authorization is what makes the activity lawful and scoped rather than an intrusion.
Authorized security validation — the written boundary
Active security validation is performed only under a written authorization that names the targets, the permitted methods, the operating windows, the explicit stop conditions, the evidence-handling rules, and the Rules of Engagement. Authority over the named targets must be held by the party granting it. The written scope is the boundary of the engagement in both directions: it is what we are permitted to do, and it is the limit we do not exceed. An engagement without that written grant does not begin.
Rules of Engagement, in practice
The Rules of Engagement convert the written scope into operating discipline: which targets are in and out of bounds, which techniques are permitted and which are prohibited, the hours during which activity may occur, the conditions under which activity halts immediately, and the named contacts on both sides who can be reached without delay. A stop condition is honored the moment it is met, not when the task is convenient to pause. The point is that an authorized engagement is governed throughout, not just approved at the start.
Findings, evidence, and retest
A technical finding preserves the conditions needed to reproduce it and the evidence needed to review it, kept separable from interpretation so a reader can walk from observation to conclusion without taking the examiner's word for a step. Evidence is handled under the terms set in the authorization and is not retained or reused beyond them. Retest is performed against the defined finding and the agreed remediation — it confirms the specific thing was fixed, and stands as exactly that — a confirmation of the named remediation, scoped to the finding rather than extended to the whole system.
What we do not claim
We do not claim that any system is secure in the absolute, that a passed test proves robustness, or that an authorized engagement covers more than its written scope. Tested-once is not robust, and a clean result certifies the test that ran, not every path that exists. Security here is a posture maintained and evidenced, not a state declared — the honest position for anyone who takes the work seriously.