Skip to content

Boards Cloud Security

How Huddo Boards Cloud authenticates users, protects data in motion and at rest, and what it stores.

For the equivalent controls on a self-hosted deployment, see Security and Session Expiry.

Authentication

Topic Detail
Sign-in OAuth 2.0 / OIDC against the customer's identity provider: Collab Cloud, Microsoft 365, Google, Apple ID, LinkedIn, Facebook, Microsoft Entra ID (Azure AD), HCL Connections (cloud or on-premises), HCL Domino, HCL DX, or Auth0.
Passwords None. Boards never receives, stores or verifies a user password — authentication always happens at the identity provider.
Session Sign-in returns a signed JWT bearer token used for all subsequent API calls. A cookie-based session is used only for image and file requests, where a browser cannot send an Authorization header.
Token signing HMAC-SHA256 with a per-deployment secret.
API keys Users can mint long-lived API keys for integrations and calendar feeds. Each key expires independently and can be revoked without affecting the others.
MCP / AI assistants The MCP server is a separate OAuth 2.1 public client with PKCE enforced (no client secret). It calls the same Boards API as any other client and inherits the signed-in user's permissions — it has no direct database access.

Session and key lifetimes

Credential Default lifetime
Browser session 90 days from sign-in
API key 365 days from creation
API key in active calendar-feed use Extended automatically before expiry so feeds keep working

What provider data is stored

Data Purpose
Basic user profile (display name, email, subscriber ID, customer ID) Identify and address users, board membership
User and community photo Avatars
Community / space / group name and members Board access control
Links to files Attachments reference the provider's file store; file contents are not copied
Imported Connections Activities Only when a user explicitly runs the import

Data in motion

Connection Encryption Authentication Notes
User browser ➡️ Boards TLS (HTTPS) JWT bearer token for API calls; session cookie for images and file downloads HSTS is sent on every response
Boards ➡️ MongoDB Atlas TLS SCRAM username/password IP allow-list; traffic stays on the Google Cloud network
Boards ➡️ Object storage TLS S3 HMAC access key / secret key Internal Google Cloud network; the bucket has no public access
Boards ➡️ Providers (Connections, Microsoft 365, etc.) TLS OAuth 2.0 access tokens Outbound calls leave from a fixed NAT IP — see Hybrid Security

HTTP security headers

Every response from Boards Cloud carries:

Header Value Purpose
Strict-Transport-Security max-age=15724800; includeSubDomains Forces HTTPS for ~6 months
X-Content-Type-Options nosniff Prevents MIME-type sniffing
Referrer-Policy strict-origin-when-cross-origin Limits referrer leakage to third parties
Cross-Origin-Resource-Policy cross-origin Required so Boards can be embedded in customer portals
Content-Security-Policy Enforced policy (see below) Limits where scripts, styles, frames and form posts may come from
X-Powered-By (removed) No server technology disclosure

What the Content-Security-Policy enforces

Boards Cloud serves an enforced policy (not report-only). Boards origins are the Boards site and its API; provider host is the customer's identity-provider host (HCL Connections, Collab Cloud, Microsoft 365) where that provider injects a header or SSO banner into the page.

Directive Allowed Why
default-src 'self' Fallback for anything not listed below
script-src 'self', 'unsafe-inline', 'unsafe-eval', provider host, payment and Microsoft Office add-in hosts See the note below
style-src 'self', 'unsafe-inline', provider host Rich-text formatting is rendered as inline styles; the provider banner injects styles
img-src 'self', data:, blob:, https: Avatars and thumbnails render from memory; board content may reference images on any host
font-src 'self', data:, provider host, Microsoft font CDNs Bundled fonts, plus the provider and Microsoft 365 header icon fonts
connect-src 'self', Boards API (https: and wss:), provider host API calls, file downloads and live updates
media-src 'self', Boards API Video and audio preview
frame-src 'self', Boards API, payment host HTML file preview and payment flows render in an iframe
form-action 'self', Boards API, provider host Restricts where forms may post — blocks form hijacking
worker-src 'self', blob: Offline service worker and the PDF preview worker
object-src 'none' Nothing uses plugins
base-uri 'self' Stops an injected <base> tag redirecting relative URLs

Inline scripts — an HCL Connections requirement, not a Boards one

Boards' own code runs under script-src 'self'. 'unsafe-inline' and 'unsafe-eval' are present only because the HCL Connections and Collab embedded SSO header injects inline scripts (which cannot be hashed, as they are generated per request) and its Dojo toolkit evaluates code at runtime. Boards Cloud serves every customer from one origin, so the policy has to accommodate the customers who use that header.

This is an accepted and tracked risk; residual XSS impact is limited by object-src 'none', base-uri 'self', form-action and nosniff. Self-hosted deployments that do not load the Connections header — Microsoft 365, HCL Domino, HCL DX, Auth0 and standalone — should not grant either directive.

Self-hosted deployments

Self-hosted Boards ships without an enforced CSP so it cannot break an existing integration on upgrade. To apply your own — including worked examples for Component Pack, split host names and standalone deployments, and how to validate a policy in report-only mode first — see Security. The same page covers restricting who may embed Boards (CORS_ALLOWED_ORIGINS) and tuning HSTS.

Cross-origin access and framing

Boards is designed to be embedded in customer portals whose URLs are not known in advance (HCL Connections, Microsoft Teams, Outlook, Verse, custom intranets). Because of this:

Control Position
CORS The API reflects the requesting origin only for its own frontend or a caller presenting an Authorization header, and always sends Vary: Origin. A request relying only on the ambient session cookie is not reflected, so a third-party site cannot read a signed-in user's API responses.
CSRF APIs accept JSON request bodies only, which a cross-site form cannot produce without a preflight. Entity IDs travel as URL path parameters; no data is passed in query parameters.
Framing Permitted, by design, so Boards can be embedded. Self-hosted deployments can lock framing to a known origin list with CORS_ALLOWED_ORIGINS.
SQL injection Not applicable — Boards uses MongoDB, not a SQL database. Queries are built through the Mongoose ODM, not string concatenation.

Rate limiting

The API applies per-IP rate limits over a rolling window, with separate ceilings for authenticated and unauthenticated requests and tighter limits on selected endpoints. Requests over the limit receive 429 Too Many Requests.

Data at rest

Most data is stored in MongoDB Atlas, hosted in Google Cloud (EU West). User images and file attachments are stored in Google Cloud object storage.

Control MongoDB Atlas Google Cloud object storage
Encryption at rest Yes — AWS KMS-encrypted storage engine and backups Yes — Google-managed keys
Network access IP allow-list; each Atlas group runs in its own VPC No public access; reachable only by Boards servers
Authentication SCRAM credentials, two-factor authentication on the Atlas console S3 access key / secret key
Patching Applied automatically by MongoDB engineers Managed by Google

More detail on MongoDB's compliance posture is available on the MongoDB Trust Center.

Hosting and data residency

Item Detail
Cloud provider Google Cloud
Region EU West
Database MongoDB Atlas, same region
Outbound IP Fixed NAT address — see Hybrid Security

Security testing

Boards is scanned with HCL AppScan (static and dynamic analysis) on an ongoing basis, and findings are triaged and tracked to closure. Dependencies are updated continuously via automated dependency management.

Privacy

Our privacy policy is published at huddo.com/privacy-policy.