Fragile Labs
Security

Security at Fragile Labs

Fragile Labs uses layered identity, authorization, application, and infrastructure controls to protect its services. This statement describes the controls in place today, how responsibility is shared, and how to report a vulnerability.

Effective August 13, 2026 · Last updated August 13, 2026

Scope and approach

This security statement applies to Fragile Labs-operated services, including fragilelabs.co, signup.fragilelabs.co, the Fragile identity platform, Fit, Sunday Money, and Fragile Admin. Our program is designed around least privilege, explicit trust boundaries, tenant isolation, short-lived authorization, and auditable administrative changes.

Security is a shared responsibility. Fragile Labs protects the platform and the controls it operates. Customers and users are responsible for securing their devices, credentials, recovery material, connected accounts, and the membership and role assignments they control.

Identity and access management

  • Authentication options. The identity platform supports passkeys, passwords, time-based one-time passwords, recovery codes, and verified email recovery. Device biometrics such as Face ID protect credentials and local app access on supported devices; they do not replace server-side authorization.
  • Privileged access. Administrative functions require a current identity-provider session and a server-verified superadministrator designation. Sensitive account settings require recent authentication.
  • Application separation. Each web or mobile application is registered as a separate OpenID Connect client with its own approved redirect destinations and permitted scopes. Public mobile clients do not contain client secrets.
  • Role-based authorization. Product access, organizational membership, household membership, and roles are distinct records. APIs enforce authorization against the relevant application and tenant; the platform does not rely on a hidden button or client-supplied role as an access control.
  • Revocation. Changes to application access and membership affect subsequent authorization decisions and token issuance. Password resets, account recovery, device loss, and administrative revocation can require a user to authenticate again.

Application and API security

  • Standards-based authorization. Fragile applications use the OAuth 2.0 Authorization Code flow and OpenID Connect. Native clients use PKCE. Application integrations are required to validate the issuer, audience, signature, expiration, state, and nonce as applicable.
  • Short-lived access. Identity and access tokens are intentionally short-lived. Refresh credentials are restricted to approved clients and are subject to rotation, revocation, and maximum-session rules.
  • Browser token handling. Fragile web application architecture keeps access tokens, refresh tokens, ID tokens, and confidential client secrets out of browser JavaScript. Browsers receive an opaque, secure, HTTP-only, same-site application session cookie.
  • Request protections. Identity and administrative endpoints apply origin checks, input validation, bounded invitation tokens, and rate limits for login, registration, recovery, verification, invitation, and administrative activity.
  • Failure behavior. Authorization and internal-service authentication failures are designed to fail closed. Production identity services do not expose internal errors to users.

Data and infrastructure protection

  • Transport security. Public Fragile Labs services are delivered over HTTPS. Production callback and redirect destinations must use exact HTTPS addresses; wildcard and parent-domain callbacks are not accepted as application integration policy.
  • Network boundaries. Identity administration endpoints, databases, and control-plane service interfaces are intended to remain on Railway private networking. Internal APIs require service authentication in addition to network location.
  • Secret management. Production secrets are supplied through deployment configuration and are not committed to source control. Separate secrets are used for application clients and external providers where the architecture requires them.
  • Tenant boundaries. Gym and household records are scoped to their organization. Application APIs are responsible for checking that scope on every protected operation.
  • Payment data. Stripe processes payment-card information. Fragile Labs stores the identifiers and subscription state needed to provide access, not full payment-card numbers.

Logging and administrative accountability

Fragile Labs records security-relevant and administrative events needed to investigate activity and reconstruct access changes. This includes changes to application entitlements, memberships, roles, identity administration, billing state, and bug-report status. Access to operational data is limited to authorized administrative functions.

Logs support investigation and service operation; they are not a substitute for authorization checks. Fragile Labs does not intentionally place passwords, session cookies, access tokens, recovery codes, client secrets, or full Stripe payloads in application logs.

Service providers

Fragile Labs relies on specialized providers for portions of the service, including Railway for application infrastructure, Cloudflare for DNS and edge services, Stripe for payments, Plaid for financial-account connectivity, Resend for transactional email, and Apple and Google for app distribution and platform services. Those providers operate their own security programs and controls. We limit integrations to the access needed for their function and reassess the integration when its purpose or data scope changes.

Security incidents

When Fragile Labs identifies a suspected security incident, we assess its scope and impact, contain affected access where possible, preserve relevant evidence, remediate the cause, and evaluate notification obligations. If applicable law requires notice to affected individuals, business customers, or regulators, we will provide it within the required period.

Report suspected account compromise, an unrecognized access or membership change, or a security concern to [email protected]. Do not send passwords, recovery codes, financial credentials, or access tokens by email.

Vulnerability disclosure policy

Security researchers may report a suspected vulnerability to [email protected] with the subject “Security report.” Include the affected service or URL, the conditions required to reproduce the issue, its observed or potential impact, and a safe proof of concept when available. Reports may also follow the contact information published in our security.txt file.

We aim to acknowledge a credible report within three business days. Investigation and remediation time will depend on severity, exploitability, affected systems, and the availability of a safe corrective release.

Good-faith research

Fragile Labs will not initiate legal action against research conducted in good faith and in accordance with this policy. To remain within this policy:

  • Test only accounts, devices, organizations, and data that you own or are expressly authorized to test.
  • Stop testing and notify us promptly if you encounter another person’s data, credentials, or private communications.
  • Access and retain only the minimum information needed to demonstrate the issue, and securely delete it after the report is resolved.
  • Do not perform denial-of-service testing, destructive actions, high-volume automated scanning, social engineering, phishing, spam, physical attacks, or attacks against third-party providers.
  • Do not alter data, establish persistence, move laterally, degrade service, or use a vulnerability for financial gain.
  • Allow reasonable time for investigation and remediation before public disclosure.

This policy does not authorize activity that violates applicable law or the rights of another person. It is not a bug-bounty program and does not promise compensation.

Assurance and limitations

No internet service can guarantee absolute security. This statement describes Fragile Labs practices and architecture; it is not a representation that every threat can be prevented. It does not claim compliance with, or certification under, a security framework such as SOC 2, ISO 27001, PCI DSS, or HIPAA. Stripe, rather than Fragile Labs, handles payment-card processing.

We review this statement as the platform and its controls change. Material changes will be reflected by the “Last updated” date above. Questions about this statement may be sent to [email protected].