Skip to main content

Security policy

Supported versions​

Only the latest published minor of @ltv/cwb receives security fixes. The package is pre-1.0, so a minor release may contain breaking changes (see the changelog and the migration guide). Full policy: support policy.

Reporting a vulnerability​

Do not open a public issue

Report security problems privately through GitHub's Security → Report a vulnerability on ltv/cloudflare-workers-bootstrap, or contact the maintainers directly.

Include:

  • the affected version;
  • the impact, for example tenant data exposure or secrets in logs;
  • reproduction steps or a failing test.

Security-relevant behavior​

These behaviors are covered by the library's test suite.

Error exposure​

  • Production is assumed unless NODE_ENV is development, dev, test or local.
  • 5xx messages and details are masked in responses, and raw driver or D1 messages never reach clients.
  • ApiError.toJSON() omits the stack.

See Error handling.

Error logs​

ErrorInfo.details are always logged and reported (only responses mask them), so keep secrets out of details.

Redaction​

Sensitive headers and query parameters are redacted in logs and error reports, by exact name and by name fragment. errors.context.includeClientInfo: false also removes the client IP and user agent. See Redaction.

Request ids​

The client-spoofable cf-request-id header is ignored and cf-ray is format-checked. requestId: {trustIncomingHeader: false} ignores client-supplied ids entirely.

Error visibility​

Throttling never suppresses 5xx or critical errors, so floods of 4xx errors can't hide server errors.

Tenant isolation​

  • Tenant state is per request, and cache namespaces are per tenant. Datasource classes are abstract with a required name, so different datasources never share a cache namespace by default.
  • scopedSelect and scopedCount cover filtered, ordered and paginated reads without touching the unscoped db.
  • The scoped* write helpers return narrow queries that can't bypass the tenant filter.
  • ds.db is unscoped by design, for system queries.
Your responsibility

The library enforces the tenant it is given. Resolving that tenant from verified credentials, and adding ds.where() to every custom query, join and relational include on ds.db, is up to your application. See Multi-tenancy.

Middleware​

Use createApp({middleware}) or ApiModule.middleware for authentication. Middleware added with app.use() after createApp does not guard module routes. See App builder.