Security

Encryption in transit

All traffic to iterateTo — the dashboard, the ingest endpoint, the widget config API, and the REST and MCP APIs — is served over HTTPS (TLS). The embeddable widget submits feedback to the ingest endpoint over the same encrypted channel.

Storage and data at rest

Feedback records and screenshots are stored in a managed MongoDB Atlas database with encryption at rest provided by the platform. Screenshots are kept in a dedicated storage bucket and are served only through organization-checked endpoints. We store a one-way hash of each sender’s IP address for spam control — never the raw IP.

Access controls

Data is scoped to organizations (the tenancy unit). Every dashboard page, server action, and API request resolves the caller’s organization and filters all queries to it, so one tenant cannot read or modify another’s data. API and MCP access uses secret, revocable keys; a request for a resource outside the key’s organization simply matches nothing.

Client-side screenshot masking

Screenshots are captured and masked in the reporter’s browser, before any pixels are transmitted. Elements the host site marks with data-feedback-mask are hidden automatically, elements marked with data-feedback-ignore are excluded from capture, and reporters can paint additional redactions that are baked destructively into the image locally. The masked regions never leave the device.

Shared responsibility. Automatic masking is a safety net, not a guarantee. Because host pages vary, customers are responsible for marking sensitive elements with the provided attributes and for reviewing what their integration exposes. Reporters should confirm a screenshot looks right before sending.

Abuse and rate limiting

The public ingest endpoint is protected by layered controls: per-key and per-sender rate limits, payload size caps, a honeypot field, a submission time-trap, and an optional origin allowlist. These reduce spam and abuse without custom headers that would require CORS preflight.

Incident response

We intend to investigate suspected security incidents promptly, contain and remediate confirmed issues, and notify affected customers without undue delay so they can meet their own obligations. Our processor commitments on breach notification are in the Data Processing Addendum.

Handling data-subject requests

Customers can fulfil access, export, and erasure requests directly: export a project’s feedback as CSV or JSON, and erase a specific person’s data by email, from project settings or the REST API. Deleting a project cascades to all of its feedback and screenshots. See the Privacy Policy for the mechanisms.

Reporting a vulnerability

If you believe you have found a security issue, please email security@iterateto.example with details and steps to reproduce. We appreciate responsible disclosure and will acknowledge reports as quickly as we can.