Security

Notarus runs inside your customers' browsers and holds what they report. This page describes the mechanisms that protect it. Everything here is behaviour you can verify in the product, not a statement of intent.

One place decides access

Permission checks live in a single module. The panel's HTTP routes and the MCP server both call it, which means an agent operating your project is bound by exactly the roles you granted the person holding the token — there is no second, looser path into the same data. Removing someone from a project ends their access immediately, including any review session already open.

Credentials

• Sign-in never happens in the browser. The application server is the only party that talks to the identity provider; the panel never holds the provider's secret key. Sessions are carried in HTTP-only cookies and refreshed server-side.
• API tokens are stored as digests, not as secrets. A personal access token is shown once at creation. What we keep is its SHA-256 digest; verification looks the token up by its non-secret prefix and then compares digests in constant time, so a wrong guess takes the same time as a near-miss.
• Revocation is immediate. Deleting a token stops the next request that uses it. There is no cache to expire.

Isolation between accounts

Every table in the database has row-level security enabled and denies access by default, and the database's own public REST API is switched off. The application server is the only door, and it reaches the database exclusively through parameterised queries — string-built SQL does not exist in the codebase. Those are two independent layers: the second would still hold if the first were misconfigured.

The widget on your page

The widget renders inside a Shadow DOM, so your stylesheet cannot leak into it and its stylesheet cannot leak into your page. It is bound by a performance contract as well as a security one: it degrades rather than competing with your site for resources, and it is designed never to break the page it is embedded in.

What the capture refuses to record

Some protections are properties of the code rather than settings. Request and response bodies are never read. Typed input is masked in session replay, unconditionally. Keys that look like credentials — authorization, cookie, password, token, secret, api key, assertion — are redacted before anything is stored, and a project can add keywords to that list but cannot remove any. IP addresses are stored only as a one-way salted hash, if at all. The privacy page covers what is collected in full.

Media

Screenshots and recordings are served through signed, expiring URLs whose signatures are verified in constant time. A media link is not a permanent public address, and sharing one does not hand over lasting access.

The public surfaces

The endpoints an anonymous visitor can reach — feedback ingest, session tracking, the reporter portal and the MCP endpoint — are rate limited independently of one another, so pressure on one does not degrade the rest. The product site itself is served under a strict Content Security Policy with no inline scripts.

The audit trail

Every administrative change — over HTTP, over MCP, on invite acceptance, on billing reconciliation — records the attempt before the state changes and the outcome after it. The log is immutable and its metadata is allowlisted: credentials, passwords, tokens, webhook secrets and request bodies are never written to it. Project admins and owners can read it.

What we do not claim

Notarus holds no security certification, and this page deliberately claims none. If you need SOC 2, ISO 27001 or a signed data-processing agreement to adopt a tool, we do not have them yet — and saying so is more useful to you than a badge that means nothing.

Reporting a vulnerability

If you find a security issue, report it to the operator of the instance you are using before disclosing it publicly, and give them a reasonable window to fix it.