Security threats and responsibilities
This guide helps administrators review a self-hosted Mockarty installation before connecting it to real systems or giving a team access. It uses the STRIDE categories to show what can go wrong, which Mockarty controls are relevant, and what remains for your organisation to manage. It is a planning aid, not a certification or a substitute for testing your deployment.
For configuration steps, see Administration and Security and compliance.
1. System summary
Users and automation connect to the Mockarty admin service through the UI, API, CLI, or SDK. The installation can also run resolvers and test runners. These components may process mock definitions, test requests, results, credentials, and audit records. Decide which networks and people may reach each component before enabling access.
2. Assets
| Protect | Why |
|---|---|
| Mock definitions, test inputs, and results | They may contain API details or data copied from a test system. |
| User accounts, sessions, and API tokens | They control access to workspaces and automation. |
| Secrets used by integrations | Exposure can grant access to external systems. |
| Audit records and backups | They support investigations and recovery. |
| Release files and container images | A modified package can compromise the installation. |
Use synthetic data where possible. If a test must use sensitive data, give access only to the people who need it and define how long to retain the results.
3. Trust boundaries
| Boundary | What to review |
|---|---|
| Users and automation → admin service | TLS, authentication, role assignments, and API token scope. |
| Admin service → workspaces | Namespace membership and access to shared test data. |
| Mockarty → systems under test | Allowed target hosts, network egress, and written test authorisation. |
| Mockarty → storage and backups | Database access, backup protection, and retention. |
| Installation → external identity or model provider | Provider permissions, credentials, and data sent outside your network. |
4. STRIDE analysis
S — Spoofing identity
Risk: someone signs in as another user or reuses a leaked API token. Mockarty controls: account roles, scoped and revocable API tokens, and MFA where configured. Your action: require MFA for privileged users, keep tokens out of repositories and logs, and revoke a token when its owner or purpose changes. Review identity-provider settings if you use external login.
T — Tampering
Risk: a user changes mocks, test settings, or results without permission. Mockarty controls: role checks and audit records for protected actions. Your action: grant the smallest useful role, review changes to shared workspaces, and protect the database and backups from direct modification.
R — Repudiation
Risk: after an incident, the team cannot tell who changed a setting or started a test. Mockarty controls: audit records for administrative and user actions. Your action: set a retention period, send records to your monitoring system if needed, and make sure administrators can investigate unusual activity. See Administration for audit settings.
I — Information disclosure
Risk: a user reads another workspace’s data, or a report contains credentials or personal information. Mockarty controls: workspace access checks and optional protection for stored personal information. Your action: review namespace membership, inspect reports before sharing them, and enable PII encryption when your deployment requires it. The default install does not enable PII encryption; configuration is described in Administration.
D — Denial of service
Risk: a load, fuzz, or chaos test overwhelms Mockarty or the target system. Mockarty controls: test limits and cancellation controls. Your action: start with small runs, schedule disruptive tests in an approved window, monitor both Mockarty and the target, and size runners for expected load.
E — Elevation of privilege
Risk: a user gets more access through an API call or an overly broad role. Mockarty checks access at the API as well as in the UI. Four system roles (Admin, Support, User, Auditor) and workspace roles govern what users can do. Your action: review role assignments regularly, give automation dedicated tokens, and verify access with a test account before sharing a workspace.
5. Supply chain
Obtain releases from your approved distribution channel and verify any published checksums before installation. Keep the host, database, reverse proxy, and container runtime patched. If your organisation mirrors packages internally, protect the mirror and record which version was deployed.
6. Residual risks
Mockarty cannot protect a compromised identity provider, a stolen administrator credential, or data copied into a test payload by a user. People with direct database or host access may bypass application controls. Network policies, identity-provider settings, backup protection, and incident response remain part of your deployment responsibilities.
Review this guide again when you add integrations, expose new networks, change roles, or begin testing a system that contains sensitive data.