Security & trust

Widget isolationCopy Anchor Link

The widget UI renders inside a sandboxed iframe served from the Annot8 origin. Two consequences, both deliberate:

• Your site's CSS cannot break the widget, and the widget's styles can never leak into your page.
• The cross-origin iframe cannot directly read the host page's cookies or storage. The separately installed host script runs on the customer's page and captures the configured page context. Iframe isolation does not make that host script unable to access page content; review the capture and privacy settings.

There is intentionally no custom-CSS hook, because it would require giving up that boundary.

Domain allow-listingCopy Anchor Link

A project's environments define which hostnames the widget may run on. A page whose hostname matches nothing gets nothing.

A bare * wildcard is rejected — there's no configuration that makes the widget embeddable from any origin.

Origin-validated widget sessionsCopy Anchor Link

Before any public write is accepted, the widget requests a session token. Annot8 validates the browser-sent Origin header against the project's environment patterns, and only then issues a short-lived token. Writes without a valid token are rejected.

The project key is a public identifier, not a secret or proof of visitor identity. Origin checks constrain browser integrations; they do not authenticate a person or prevent a non-browser client from supplying an Origin header. Short-lived capabilities, authorization checks and abuse limits serve different purposes.

Integration credentialsCopy Anchor Link

Third-party credentials — API tokens, webhook URLs — are encrypted with AES-256-GCM before being stored, using an envelope scheme that supports key rotation using a previous key during a coordinated transition.

They're only ever decrypted server-side at delivery time. They are never returned to the browser, never included in a client query, and never rendered back into the settings form.

Access controlCopy Anchor Link

• Workspace isolation. Dashboard access is checked against workspace membership server-side, not only in the UI. Public feedback and widget paths have separate, deliberately limited authorization rules.
• Role permissions. Owner, admin, and member map to a fixed permission set, enforced on the server. See Team members.
• Guest scope. A public link does not grant dashboard access. Public portals intentionally display published posts and comments; do not put confidential content on a public surface.

Content reportsCopy Anchor Link

Public surfaces need a reporting path, so the feedback portal has one:

Removed content is marked with a reason rather than silently disappearing, so the record of what happened survives.

Data handlingCopy Anchor Link

What the widget collects, what it deliberately doesn't, and how screenshots are redacted is covered in What gets captured and Privacy.

Reporting a vulnerabilityCopy Anchor Link

Email security@annot8.app. Please include enough detail to reproduce, and give us a reasonable window to fix before disclosing.

DocumentsCopy Anchor Link

Annot8 does not claim a SOC 2 report or HIPAA-supported processing. Do not submit PHI. Provider certifications do not extend automatically to Annot8, and technical controls alone do not establish GDPR compliance. The public DPA is a template requiring execution, including the applicable processing and transfer schedules.