Security fixes

We closed gaps where some authorization checks weren't consistently enforced: certain entity-write actions and the Settings area could be reached by roles that shouldn't have had access. Role permissions are now enforced on entity writes, Settings is restricted to administrators and managers, and the Manager system role was completed so role names resolve correctly. No abuse was observed; this tightens least-privilege enforcement across the admin application.

The admin application previously kept its session token (a JWT) in the browser's localStorage. A script injected through a cross-site-scripting flaw could read it from storage and reuse it elsewhere. The token is now carried in an HttpOnly, Secure, SameSite=Strict cookie that page scripts cannot read, and it is no longer written to localStorage; the live-updates WebSocket also authenticates from that cookie instead of a token placed in the URL. This is defense-in-depth — we have no report of an exploit — that limits the reach of any future cross-site-scripting flaw to a single browser tab rather than a portable, stealable token. The platform-admin and organization-admin consoles received the same treatment.

Tenants choose which sites may embed their hosted forms in an iframe, and FastYoke enforces that allow-list with a Content-Security-Policy frame-ancestors directive. Origin comparison is now scheme-exact: a bare host on the allow-list matches only its https:// origin, and an entry that already includes a scheme matches that scheme exactly. Previously the scheme was disregarded when comparing, so an insecure (http://) variant of an allowed host could satisfy the check. No abuse was observed; this tightens the embedding boundary against a downgraded-origin framing attempt.

A moderate advisory (CVE-2026-45736) in the ws Node WebSocket library reported that websocket.close() could disclose uninitialized memory when given a typed-array reason argument. In FastYoke ws appears only as a build-, development-, and test-time transitive dependency (Nuxt tooling and the test DOM environment); the shipped product uses the browser's native WebSocket on the client and a Rust WebSocket server on the backend — neither is the ws library — so no shipped release was exposed to the vulnerable path. We updated to ws ≥ 8.20.1 to clear the advisory and keep the dependency tree clean.

A bug in lettre 0.11.21's boring-tls integration silently disabled TLS hostname verification for callers on that backend. FastYoke compiles lettre with rustls, so no shipped release of FastYoke was exposed to the vulnerable code path. We bumped to 0.11.22 to clear the advisory and remove the flagged crate from our dependency tree.

The backend previously fell back to a permissive Access-Control-Allow-Origin: * when CORS_ALLOWED_ORIGINS was unset. We changed production deploys to refuse to start without an explicit allow-list, matching the fail-closed posture used for the JWT signing secret. Sandbox and local-dev environments keep the permissive fallback so browser-based testing isn't blocked.

We ran a comprehensive audit of the API layer covering tenant-isolation gaps, SSRF egress vectors, authentication hardening, and reflected XSS surfaces. All findings were remediated and shipped before any release of v3 reached general availability.

The endpoints that list and read integration connections previously allowed any authenticated identity to enumerate which providers a tenant had configured — a useful reconnaissance signal for an attacker holding a low-privilege token. They now require the same permission that gates connection creation and deletion. The cancel endpoint for FSM jobs was also tightened to resolve the tenant id from the session, not from request input.

Three unauthenticated request paths — login, invitation acceptance, and public form submission — previously had no per-IP throttle and were bounded only by CPU. Each now mounts a token-bucket limiter with a Retry-After response on rejection. Login and invitation acceptance throttle per source IP; form submission throttles per (source IP, form slug) so cross-form abuse from one IP is caught while a single user submitting to multiple forms is not penalised.