# Detour safety checklist

Status: release gates to implement and verify. These are not claims that the
current prototype has passed an audit.

## Local server and MCP

- [ ] Confirm Docker publishes only to `127.0.0.1` by default. Reject unexpected
  `Host` and `Origin` values on the web API and future MCP endpoint. Test DNS
  rebinding and cross-origin writes against the local server.
- [ ] Decide how the harness authenticates to local MCP. Prevent another local
  process or browser tab from invoking write or executable tools by accident.
- [ ] Validate all API and MCP inputs: body size, schema, record IDs, paths,
  query limits, and output encoding. Fuzz malformed JSON and oversized payloads.
- [ ] Treat imported docs, MCP tool descriptions, and tool output as untrusted
  content. Test prompt injection that tries to read files or export secrets.
- [ ] Give read tools, write tools, and executable tools distinct permissions.
  Show the full proposed action before destructive or sharing operations.

## Container and local capabilities

- [ ] Run as a non-root user. Drop unused Linux capabilities, set
  `no-new-privileges`, and make the application filesystem read-only where
  practical. Keep the data volume as the only default writable mount.
- [ ] Never mount the Docker socket or the whole home directory by default.
  Review each optional mount before a tool starts.
- [ ] Launch SQL, file, and test capabilities only when enabled. Give each one
  explicit database or directory scope, timeouts, resource limits, and a stop
  control. Test path traversal, symlink escape, command injection, and runaway
  processes.
- [ ] Pin the base image and application dependencies; scan both in CI and
  review updates. Keep a reproducible release image.

## User data and sharing

- [ ] Make a backup and restore the SQLite volume into a fresh container.
  Include schema migration and interrupted-write recovery tests.
- [ ] Preview the exact export manifest and content. Test that unselected,
  archived, and secret-bearing records do not leak through bundle metadata,
  Markdown, JSON, logs, or error responses.
- [ ] Bound import file size and record count. Validate format versions and
  types; reject unexpected paths and executable content; round-trip an export
  into a separate container.
- [ ] Keep secrets out of logs, analytics, diagnostics, and hosted link metadata.
  Define clear local delete and backup retention behavior.
- [ ] For hosted links later: require an account, issue unguessable tokens, set
  short expiry and revocation, limit downloads, and serve only a selected
  snapshot. Test that links cannot reach the source container or other exports.

## Release evidence

- [ ] Record passing unit, API, import/export, and adversarial security tests.
- [ ] Review the threat model for new MCP tools, mounts, and hosted sharing.
- [ ] Verify the built image and dependency scan, then publish a versioned
  changelog with known limitations.

Current evidence: Compose binds `127.0.0.1:3787` and persists SQLite in a
named volume. The Python server currently has an unauthenticated local HTTP
API; there is no MCP endpoint, import flow, tool execution, or hosted sharing
service yet. The checks above must be completed before claiming those features
are safe for real user data.

References: [OWASP MCP Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html),
[OWASP ASVS](https://owasp.org/projects/asvs),
[OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html),
[Docker Compose service security options](https://docs.docker.com/reference/compose-file/services/),
[Docker Engine security](https://docs.docker.com/engine/security/).