# Security & trust

How the widget is isolated, how credentials are stored, how access is controlled, and how public content is moderated.

Source: https://docs.annot8.app/docs/security/overview



## Widget isolation [#widget-isolation]

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-listing [#domain-allow-listing]

A project's [environments](/docs/dashboard/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 sessions [#origin-validated-widget-sessions]

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 credentials [#integration-credentials]

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 control [#access-control]

* **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](/docs/dashboard/team-members#roles).
* **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 reports [#content-reports]

Public surfaces need a reporting path, so the
[feedback portal](/docs/feedback/portal) has one:

<Steps>
  <Step>
    ### Anyone can report [#anyone-can-report]

    A visitor reports a post or comment. They receive a **receipt link** they can
    revisit at any time to see the current status.
  </Step>

  <Step>
    ### Your team reviews [#your-team-reviews]

    Reports land in **Project → Moderation**. States are: received, under review,
    action taken, no action, and appeal under review.
  </Step>

  <Step>
    ### The reporter can appeal [#the-reporter-can-appeal]

    If they disagree with the outcome, they can appeal from the same receipt link,
    which reopens the report for review.
  </Step>
</Steps>

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

## Data handling [#data-handling]

What the widget collects, what it deliberately doesn't, and how screenshots are
redacted is covered in [What gets captured](/docs/widget/capture) and
[Privacy](/docs/security/privacy).

## Reporting a vulnerability [#reporting-a-vulnerability]

Email [security@annot8.app](mailto:security@annot8.app). Please include enough
detail to reproduce, and give us a reasonable window to fix before disclosing.

## Documents [#documents]

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.

| Document                 | Where                                                            |
| ------------------------ | ---------------------------------------------------------------- |
| Privacy policy           | [annot8.app/privacy](https://www.annot8.app/privacy)             |
| Terms                    | [annot8.app/terms](https://www.annot8.app/terms)                 |
| Data processing addendum | [annot8.app/dpa](https://www.annot8.app/dpa)                     |
| Subprocessors            | [annot8.app/subprocessors](https://www.annot8.app/subprocessors) |
| Security overview        | [annot8.app/security](https://www.annot8.app/security)           |
| Cookies                  | [annot8.app/cookies](https://www.annot8.app/cookies)             |