Security at BoardScore

Encryption at rest

BoardScore uses AES-256-GCM authenticated encryption to protect sensitive data at the application level before it is written to the database. This is not full-disk encryption — it is field-level encryption applied to personally identifiable information such as email addresses, organisation names, and IP addresses.

Each encrypted value receives a unique 12-byte initialisation vector generated via a cryptographically secure random source. Encrypted values are stored with a version prefix to support future key rotation. For fields that require exact-match lookups, HMAC-SHA256 deterministic hashing is used alongside encryption.

Encryption in transit

All client-server communication is encrypted via TLS, with certificates automatically provisioned and renewed. The application enforces security headers on every response: Content Security Policy with frame-ancestors 'none', X-Frame-Options DENY, X-Content-Type-Options nosniff, and strict referrer policies.

CORS is configured to accept requests only from explicitly allowed origins. Credentials are transmitted via bearer tokens in the Authorization header — never in cookies or URL parameters.

Multi-tenant data isolation

BoardScore implements schema-per-tenant isolation in PostgreSQL. Each organisation's data resides in a dedicated database schema, and every request sets the database search path to the authenticated tenant's schema before executing any query.

A tenant schema registry validates that only provisioned schemas can be queried — preventing access to non-existent or unauthorised schemas. There are no shared data tables between tenants. Cross-tenant data access is architecturally impossible through normal application pathways.

Authentication

Authentication is delegated to Kinde, a dedicated identity provider. The application never stores passwords. User sessions are managed via RSA256-signed JWT tokens, validated on every request against the provider's JWKS (JSON Web Key Set) endpoint.

Token validation checks signature, issuer, audience, and required claims including organisation, email, and roles. A server-side token blacklist ensures that revoked tokens — such as those invalidated on logout — are rejected immediately. Blacklisted tokens are hashed with SHA-256 before storage.

Authorisation and access control

BoardScore implements role-based access control with a five-tier role hierarchy: Super Admin, Organisation Admin, Approver, Assessor, and Viewer. Each role maps to a defined set of capabilities such as managing users, approving assessments, generating reports, or viewing AI usage.

Authorisation checks are enforced at the route level — each API endpoint declares the capabilities it requires. Access denials are logged to a permission audit trail that records the user, action, IP address (encrypted), and timestamp. Protected admin domains prevent removal of critical administrative access from key personnel.

Audit logging

Every record in BoardScore carries audit metadata: who created it, who last updated it, and when. Permission changes — grants, revocations, and denials — are logged to a dedicated audit table with the acting user, affected user, timestamp, and encrypted IP address.

Structured logging with categorised log levels (Security, Audit, Business Logic, API) flows into centralised observability via OpenTelemetry. Request tracing with correlation IDs allows security events to be traced end-to-end across the stack.

Input validation and injection prevention

All user input is validated through a typed validation framework with three levels: domain rules (required fields, formats), business rules (context-dependent checks), and policy rules (permissions, rate limits). Request bodies are deserialised and validated before reaching any business logic.

All database queries use the Exposed ORM with parameterised statements — there are no raw SQL strings in the application. This eliminates SQL injection by construction, not convention.

Infrastructure and deployment

The production backend runs on Google's distroless Java 21 base image — a minimal container with no shell, no package manager, and no unnecessary system utilities. The application runs as a non-root user with a read-only filesystem where possible.

Database access uses a two-user model: a migration user with DDL privileges for schema changes, and an application user with only DML privileges for data operations. This separation of privilege limits the blast radius of any application-level compromise. Connection pooling with leak detection and validation timeouts ensures database connections are managed safely.

Secret management

All secrets — API keys, encryption keys, database credentials — are injected via environment variables at runtime. No credentials are stored in the codebase. A gitleaks pre-commit hook scans every commit for accidental secret exposure, with custom rules for JWT secrets, database URLs, API keys, private keys, and certificates.