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, an OAuth token, API token or personal access token is never returned by the API and never displayed in the interface again. A connection’s webhook address, which carries its webhook secret, is shown only to the workspace’s Owners and Admins, so they can add it to a tool by hand.
• Passwords: hashed, never stored in reversible form, with a minimum length of 5 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 into Laya.net, including magic links and social sign-in. Sign in with Laya, which signs a person in to planningpoker.org from a live Laya.net sign-in, does not ask again.
• 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. A planningpoker.org sign-in made with Sign in with Laya ends after 30 days at most, or sooner with the Laya.net session that authorised it.

Access control inside a workspace

• Role-based access: Owner, Admin and Member roles carry different capabilities. Members can connect external tools and mirror their boards by default (the connectors:connect capability, which the workspace Owner can switch off per role in Settings → Permissions). Disconnecting a tool and managing its credentials need 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 your workspace connects (including the Jira board a SprintPoker session starts on) and to read and write the issues your members work on, within the projects it mirrors (and, for the external guests of a SprintPoker session, only what its host and the Jira site’s admin let them see). Boards you have not connected are never accessed.
• SprintPoker for Azure DevOps: when our extension for Azure Boards asks Laya something on a person’s behalf, its server passes Laya the Azure DevOps access token the extension holds for that person. Laya’s servers present it to Microsoft, from their own internet addresses rather than the person’s browser, only to check who the person is and what they may see and do in their organization. These checks only read: the token is never stored, logged or used to change anything, and Laya keeps only a one-way fingerprint of it, in memory, for at most 10 minutes. For a person who acts on the pairing of their organization with a workspace, or takes part in a shared session, Laya keeps their Azure DevOps user identifier and name, with the shared session’s own data. An AI hint on a work item in a shared session sends Laya’s AI provider only the work item’s number and title and the name of the field being estimated.

External sharing controls

• Public board, doc and roadmap links are unguessable secret-token URLs, read-only, and rate-limited per IP.
• A share link to a board mirrored from a connected tool, or a Laya Board for Jira link once its site is linked to a workspace, 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.