Security Overview

1 Scope and data classification

Woven ingests congregational records from a church's existing church management system and derives engagement signals from them. The following classes of data are processed.

1.1 Data not collected

Woven does not store payment instruments, card numbers, bank account details, government identifiers, or health information. Where giving is synchronized, only the transaction record is retained. Payment instruments remain with the church's giving provider.

1.2 Write access

All church management system integrations are read-only. Woven requests read scopes exclusively and contains no code path that writes to a source system. Where a church's giving is held by a provider other than its ChMS, the giving permission is omitted from the authorization request rather than requested and left unused.

2 Architecture

Woven is a multi-tenant application comprising a REST API, two single-page web applications, and a managed PostgreSQL database. Authentication is cookie-based. The API is stateless with respect to session storage.

API

Node.js / NestJS, containerized

Web clients

React SPA, served as static assets

Database

PostgreSQL, managed, TLS-only

Tenancy model

Shared schema, church_id discriminator on every table

3 Data protection

3.1 Encryption at rest

Volume-level encryption is provided by the managed database platform. In addition, Woven applies application-level field encryption to contact details and integration credentials before they are transmitted to the database, so that possession of a database copy without the separately held key material does not yield plaintext.

Algorithm

AES-256-GCM (authenticated encryption)

Nonce

96-bit, cryptographically random, unique per value

Integrity

GCM authentication tag verified on decryption; modified ciphertext fails

Encrypted fields

Congregant contact fields, and integration access and refresh tokens

Key storage

Injected via environment, not present in source control or images

3.2 Encryption in transit

Client to API

TLS 1.2+, HTTPS enforced

API to database

TLS required (sslmode=require)

API to integrations

HTTPS only, non-HTTPS endpoints rejected (Section 6.4)

3.3 Searchable encryption

Deterministic equality matching on encrypted contact fields is provided by a keyed one-way index rather than by decryption. The index key is independent of the encryption key, and the application refuses to start if the two are configured identically, preventing a single key compromise from defeating both controls.

Construction

HMAC-SHA256 over normalized input

Key separation

Enforced at process start; identical keys are a fatal configuration error

Property

Equality matching without plaintext storage, not reversible

3.4 Key management

Key material is supplied through the deployment environment and validated at startup for length and encoding. Keys are not logged, not returned by any API, and not written to persistent storage by the application.

4 Access control

4.1 Authentication

Woven does not use passwords. Authentication is by single-use numeric code delivered to a registered address, eliminating password reuse, credential stuffing, and password disclosure as attack classes.

Credential

6-digit code, CSPRNG-generated, time-limited

Attempt limiting

Bounded attempts per code; code invalidated on exhaustion

Request rate limit

Per-address limits enforced on both issuance and verification

Enumeration

Identical response for known and unknown addresses

4.2 Session management

Transport

HTTP-only, Secure, SameSite=Lax cookie

Integrity

HMAC-SHA256 signed, constant-time verification

Expiry

Enforced server-side on every request: 7 days staff, 90 days volunteer

Revocation

User existence re-verified per request; removal takes effect immediately

4.3 Cross-site request forgery

All state-changing methods require a double-submit token echoed from a cookie into a request header. Requests lacking a matching token are rejected before reaching application logic. Browser origins are restricted by an explicit allow-list. Wildcard and origin-reflection configurations are not used.

4.4 Authorization model

Role and permission values are read from the database on each request rather than carried in the session, so revocation is effective immediately. Campus restriction, where assigned, is applied server-side and is not a client-side display filter.

5 Tenant isolation

5.1 Controls

Every table containing church data carries a church_id column, and the tenant identity for a request is resolved exclusively from the server-side session. No client-supplied value participates in tenant resolution.

Query-level enforcement is verified by an automated control that inspects application source at build time and fails the build where a church-scoped table is read without a church_id predicate. The set of protected tables is derived from the database schema rather than maintained by hand, so tables added subsequently are covered on introduction. Cross-tenant reads are permitted only through an explicit, individually justified exception register, itself validated against current code.

5.2 Operations access

Woven maintains one administrative surface that spans tenants, used for platform operations. It is subject to additional automated controls restricting it to read-only access, a short explicit allow-list of tables, and, for person records, only those columns required to produce counts. It cannot return a name, contact detail, or any congregant-identifying attribute. Access is granted by deployment configuration rather than by any database-held role, so database compromise alone cannot confer it.

6 Application security

6.1 Injection

Database access is exclusively through a parameterizing query builder. Dynamic SQL string construction is not used anywhere in the application, and identifier interpolation is confined to schema-defined column references rather than user input.

6.2 Cross-site scripting

Web clients render through React's default output escaping. The applications contain no use of raw HTML injection APIs or dynamic code evaluation.

6.3 Browser security headers

Framing

X-Frame-Options: DENY, frame-ancestors 'none'

Referrer

Referrer-Policy: no-referrer

MIME

X-Content-Type-Options: nosniff

Features

Permissions-Policy denies camera, microphone, geolocation, payment, USB

Transport

HSTS enabled at the API

6.4 Server-side request forgery

Woven fetches URLs supplied by a church in two features: public website analysis and self-hosted ChMS connections. Outbound requests are screened against loopback, private, link-local and cloud-metadata address ranges in both IPv4 and IPv6, against internal-only hostname suffixes, and against non-HTTP schemes. Redirects are followed manually with the screen re-applied at each hop, and hostnames are resolved and the resulting addresses screened before connection.

6.5 Secure development controls

Security invariants are encoded as automated tests that fail the build rather than relying on review. Controls currently enforced include tenant scoping, volunteer disclosure limits, operations-console restrictions, volunteer record ownership, and outbound mail restrictions. Dependencies are audited for known vulnerabilities on every build.

7 Privacy and disclosure controls

Beyond conventional access control, Woven constrains what each class of user may see about a congregant. These constraints are enforced structurally rather than by interface design.

7.1 Volunteer disclosure

A volunteer asked to make contact receives a first name and last initial, the reason the connection was suggested, and shared-affinity facts that make the approach natural. The reason may include general participation context: that a person has been attending for some time, or is not yet part of a group or serving team.

The permitted structure is defined as a closed schema that rejects undeclared fields rather than omitting them, preventing inadvertent widening by upstream change. Contact details are released only after the volunteer accepts, and only for that individual. Attendance figures, engagement scores, and giving are never disclosed to a volunteer.

7.2 Outbound communication

Woven transmits email only to church staff and to volunteers the church has commissioned. Ordinary congregants receive no communication from Woven under any configuration. This restriction is enforced in the sending path and covered by automated test.

7.3 Giving data

Giving is restricted per Section 4.4 and is not used to generate outreach requests. It is retained for pastoral trend analysis and is excluded from all volunteer-facing surfaces.

8 Logging, monitoring and audit

Consequential actions are recorded to an application audit log with actor, action, subject and timestamp. Application errors are reported to an error monitoring service. Configuration is schema-validated at startup. Invalid configuration prevents the process from starting rather than degrading silently.

Audit contents

Actor, action, entity, timestamp, structured metadata

Excluded from logs

Congregant names, contact details, credentials, tokens, session values

9 Contact and review

Woven welcomes questions about this document from church staff and from any reviewers who advise them. Requests for detail beyond what is published here, including responses to a reviewer's own security questionnaire, are answered directly.

Suspected security issues may be reported at any time to the address below.