Security programme

This document describes the technical and organisational measures (TOMs) Laya applies. It is the annex a reviewer normally attaches to a Data Processing Agreement, and it is written to be checked rather than admired: every measure below is implemented in the product today.

Encryption

• In transit — all traffic to and from Laya is encrypted with TLS. HTTP Strict Transport Security is enforced, so browsers refuse to downgrade.
• At rest — the credentials Laya holds for your connected tools (OAuth tokens, API tokens, personal access tokens) and webhook signing secrets are encrypted with AES-256-GCM. Once saved, a credential is never returned by the API and never displayed in the interface again.
• Passwords — hashed, never stored in reversible form, with a minimum length of 12 characters enforced on the server rather than only in the browser.
• Backups — managed database backups inherit the provider’s encryption at rest.

Browser and transport hardening

• A Content Security Policy restricting where scripts, styles, images and connections may come from.
• Clickjacking protection — framing is denied outright (frame-ancestors none, plus X-Frame-Options: DENY).
• MIME-sniffing protection and a strict referrer policy.
• A locked-down Permissions-Policy disabling camera, microphone, geolocation and browsing-topics access.

Authentication and session security

• Ways in — email and password, single-use magic links that expire after 10 minutes, or social sign-in with Atlassian, Azure DevOps, Google, Microsoft or Slack.
• Two-factor authentication — opt-in, with passkeys (Face ID, Touch ID, Windows Hello or a hardware security key) as the primary factor, an authenticator app as fallback, and single-use recovery codes. Once enabled it is enforced on every route in, including magic links and social sign-in.
• Email confirmation — new password accounts confirm their address before the account is usable.
• Rate limiting — sign-in, account and other sensitive routes are budgeted against brute force and abuse, including per-address limits on sign-up and magic-link requests.
• Sessions — every request is authorised server-side, so revoking a session from the Active sessions list ends it immediately regardless of token age. Sessions are not silently extended by a client.

Access control inside a workspace

• Role-based access — Owner, Admin and Member roles carry different capabilities. Connecting, mirroring and disconnecting external tools require the connectors:manage capability held by Owners and Admins.
• Tenancy isolation — every request is scoped to the workspace it belongs to and checked server-side; the checks are covered by dedicated tenancy and capability test suites that fail the build if a route is added without one.
• Audit trail — workspace administrators have an Audit view recording membership changes and other significant actions.
• Least privilege on connectors — Laya acts only with the credential you grant, and uses it solely to mirror the boards you selected and to push back the edits you make. Boards you have not connected are never accessed.

External sharing controls

• Public board, doc and roadmap links are unguessable secret-token URLs, read-only, and rate-limited per IP.
• A share link can be password-protected; the password is stored hashed (Argon2id), is never returned by the API, and unlock attempts are rate-limited before any comparison is made.
• Owners choose which columns and card fields a viewer can see, and whether a read-only detail view is available at all.
• Links are revocable at any time, and are excluded from search engines by robots directives and by omission from the sitemap.

Secure development

• Changes reach production through version control and automated CI. Type checking and the full automated test suite must pass before a deployment proceeds.
• Database migrations run automatically on release; a migration that fails stops the new version from serving traffic and the previous version keeps running.
• Untrusted content rendered in the product passes through an HTML sanitiser with an allow-list policy; the sanitiser’s hostile-input cases are covered by tests that run on every change.
• Dependencies are managed with lockfiles so builds are reproducible.
• Secrets are supplied by the runtime environment and are not committed to source control.

Security testing

• Penetration testing — Laya has undergone penetration testing of the application and its APIs. Findings are triaged by severity and tracked to closure.
• Adversarial review programme — Laya has run a structured, multi-round security review across the product, with findings logged and remediated. Authentication, access control, tenancy isolation, injection, sharing and data exposure were all in scope.
• Continuous automated checks — access-control, tenancy and capability coverage suites run on every change and fail the build if a route is added without the checks it needs. Sanitiser hostile-input cases run on every change too.
• Vulnerability disclosure — an open reporting route, described below, so anyone can tell us about a problem.

Vulnerability reporting and handling

Report a suspected vulnerability to support@laya.net with "Security report" in the subject line and steps to reproduce. Please never include passwords, tokens or recovery codes in the report. We acknowledge reports, investigate, and prioritise remediation by severity and exploitability. We do not take legal action against researchers who report in good faith, avoid privacy violations and data destruction, and give us reasonable time to fix an issue before disclosing it.