Security at Hubbo

This article describes the measures Hubbo uses today. We keep it factual: no marketing claims, and no certifications we do not have.

Transport security

• The embed script, the GraphQL API, the admin app and public pages are served over HTTPS. In production the API redirects plain HTTP requests to HTTPS and sends HSTS.
• Subscriptions use secure WebSockets (wss).
• Cookies set by the API are marked Secure.
• Responses include standard browser hardening headers where applicable (for example X-Content-Type-Options: nosniff, Referrer-Policy, and CSP frame-ancestors on the admin app and landing).

Authentication and access control

• Team members sign in to the admin app through a dedicated identity provider (Auth0). Hubbo does not store your password itself.
• Every admin operation requires a signed-in user and is checked against that user’s role permissions on the server. Hiding a button in the interface is never the only control. See Roles and permissions.
• Roles follow least privilege: Writer, Designer, Support, Manager, Guest and Administrator have different default permissions that you can adjust.
• Invitations let you add or remove people from an account at any time.

Visitor-facing API

• Visitor-facing operations are limited to the client_* GraphQL operations that read published content and accept visitor input. They are identified by your account key (cookie or Hubbo-Project-Key header).
• The account key is a public identifier, not a secret, and it cannot be used to read or change your admin data. There is no public REST API.
• CORS is restricted: browsers may call the API only from the website origin saved on your account (refreshed live when you change it), from hubbo.io, and from the Hubbo admin app. Allow-listed origins receive Access-Control-Allow-Credentials together with a reflected Access-Control-Allow-Origin (never credentials without an allowed origin).
• Visitor GraphQL requires your account key (Hubbo-Project-Key / embed cookie). WebSocket subscriptions also require that key (or an admin session) at connection time, and an allow-listed Origin.
• Public chat, NPS, survey and analytics writes are rate-limited on the server. Abuse attempts from a single IP are rejected with HTTP 429. Admin AI translation/analysis and team invites are also rate-limited per account or user.

Guest chat sessions

• When a visitor starts a conversation on a notification page, Hubbo issues a short-lived guest chat token (HMAC, typically 24 hours), signed with a dedicated server secret (not the Auth0 client secret). The token is returned to the page for that browser session and may also be stored as an httpOnly hubbo_chat_* cookie on api.hubbo.io.
• Further messages and the realtime subscription for that chat require a valid guest token. Knowing only the chat id is not enough.
• Guest chats on the public page are ephemeral in the browser: refreshing the page starts a new conversation. Your team still sees every conversation in Messages.

Cookie and usage integrity

• The page-view session marker (hubbo_pv_*), the account key cookie (hubbo_api_key) and guest chat cookies (hubbo_chat_*) are httpOnly. Scripts on your page, including your own and third-party ones, cannot read or alter them.
• Usage limits are enforced on the server, not in the browser.

Widget isolation and content safety

• The widget is mounted in a Shadow DOM, so its styles and your site’s styles do not affect each other.
• Rich text shown in the widget is sanitized (allowlisted tags only). Appearance colors are validated before they are applied as CSS.
• Public Hubbo pages that are meant to be framed (notification page, public status page, public roadmap page) use CSP frame-ancestors *. Admin routes use frame-ancestors 'self' so they cannot be embedded on other sites.

Payments

Subscription payments are processed by Stripe through Stripe Checkout. Card numbers are entered on Stripe’s pages and are not stored by Hubbo. Webhook calls from Stripe are verified with a signature before they are acted on.

Operations

• Production code changes go through version control, linting and automated tests, including tests for the usage and payment logic.
• Usage counters are flushed from a separate worker process so spikes in visitor traffic do not block the API.
• Secrets such as API keys are kept in environment configuration, not in the embed bundle.

What you can do

• Give people the lowest role they need and remove people who leave.
• Do not put secrets, personal data or confidential plans into notifications, roadmaps or the status page. They are public.
• If you use a Content-Security-Policy, allow only the Hubbo hosts you need. See HTML snippet.

Reporting a vulnerability

If you believe you found a security issue, email support@hubbo.io with the subject “Security”. Describe the issue and how to reproduce it, and please give us a reasonable time to fix it before you disclose it publicly. We will acknowledge your report and keep you informed.