Security

Publisher

MargePro SASU

Hosting

OVH SAS, France (UE)

Vulnerability disclosure

contact@restorsignal.com

RestorSignal's security rests on a real boundary between the component that touches your backup and the one that holds the service's access credentials — not just on organizational measures.

1. Local runner isolation

The restore test runs inside an isolated component (restore-worker) dedicated to that single task:

• no outbound network access during the test run;
• no API key or RestorSignal credential is present in this component — a potentially corrupt or hostile dump can therefore never reach your service credentials;
• no access to the host's Docker socket;
• disposable workspace and data volume, destroyed after every run;
• resource limits (CPU, memory, process count) applied to every run.

A second, separate component (reporter) only reads the already-minimized result produced by the first, holds the service credential, and transmits that result to the Control Plane. These two components don't share the same security boundary.

2. Minimization of transmitted data

Only normalized technical metadata leaves your infrastructure: opaque context identifiers, control statuses, durations, aggregated structural fingerprints, bounded error codes. What never leaves your infrastructure: table contents, business data rows, production credentials or passwords, local file paths, or the raw backup content.

3. API key management

• Each API key (generally one per runner/server) is independent: compromising one server only requires revoking its key, without affecting the others;
• The full secret is shown only once, at creation time; only an HMAC hash is kept server-side;
• A revoked key stops working immediately, with no propagation delay;
• Each key only has access to the contexts it has been explicitly authorized for — access to another tenant's context is systematically refused (HTTP 403).

4. Multi-tenant isolation

All resources (tenants, contexts, keys, results) belong to a tenant. An authenticated request can never access the data of a tenant other than the one tied to its own key or its own session — this isolation is covered by dedicated automated tests.

5. Authentication and sessions

• Hashed passwords (Argon2id where available, otherwise bcrypt) — never stored in plaintext;
• Session cookies with HttpOnly, Secure in production, and a SameSite attribute;
• Session identifier regeneration on login;
• CSRF protection on every state-changing action;
• Basic protection against repeated login attempts (temporary lockout after several failures);
• Strict separation between operator back-office sessions, the client dashboard, and runner API keys: none of them ever grants access to the others.

6. Encryption in transit

All RestorSignal services (site, dashboard, admin, API) are exclusively accessible over HTTPS, with automatically renewed certificates.

7. Hosting

Application servers and the database are hosted by OVH SAS, in France, within the European Union.

8. Acknowledged limits

In local ("SELF-HOSTED") use, the client keeps control of the machine running the runner. RestorSignal therefore cannot guarantee that an operator with full access to that machine has not altered an entry before transmission — this is neither an anti-fraud system nor independent proof of the source backup's authenticity. These limits are documented and displayed with every result, never hidden.

9. Reporting a vulnerability

If you identify a security vulnerability in RestorSignal's services, please report it responsibly to contact@restorsignal.com before any public disclosure. We commit to acknowledging receipt and handling every report with care.