Security by design: AI Church was built for churches — communities of trust. Every security decision reflects that responsibility. We use defense-in-depth: multiple independent layers so that if one control fails, others catch it. No single point of failure exposes congregation data.
1 Our Security Commitment
Boreon Industries LLC commits to maintaining AI Church as a secure, responsibly developed platform. Our security commitments:
TransparencyWe publish our security architecture publicly. Security through obscurity is not security.
Rapid ResponseWe respond to confirmed vulnerabilities within 48 hours and issue fixes as a priority.
Defense in DepthMultiple independent controls at every layer — network, application, database, and session.
No Data CollectionWe cannot be breached for your data because we don't collect it. Self-hosted architecture is the strongest privacy guarantee.
Regular AuditsMulti-agent adversarial security reviews (Opus Ultracode) before major releases. v3.9 passed 25 findings.
Open SourceThe source code is available for review. Community security review strengthens the platform.
2 Architecture: Self-Hosted by Design
The most important security property of AI Church is its self-hosted architecture. Your congregation's data — names, contact information, giving records, attendance, pastoral notes, prayer requests — lives exclusively on your server. Boreon cannot be breached for data we don't have.
| Component | Technology | Security Implication |
|---|---|---|
| Application | Single-file PHP 8.x | Minimal attack surface; no framework CVEs from complex dependency trees |
| Database | SQLite (file-based) | No open network port; protected by .htaccess deny-all; no external DB connection string exposure |
| Hosting | Any PHP host (recommended: Infomaniak, Switzerland) | Data stays on your infrastructure under your physical and legal control |
| Front-end | Zero external CDN dependencies | No third-party script execution; eliminates Magecart/supply-chain attacks |
| AI | Your Anthropic API key (BYO) | Key stored on your server; Boreon never sees it |
3 Authentication & Authorization
Password Security
- bcrypt hashing via PHP's
password_hash(PASSWORD_DEFAULT)— industry standard, adaptive cost factor - Minimum password length enforced server-side
- No plaintext password storage anywhere in the codebase
- Default credentials detected at runtime; admins are prompted to change them; banner shown until resolved
Two-Factor Authentication (TOTP)
- RFC 6238-compliant TOTP (Time-Based One-Time Password) implemented in pure PHP — no external library dependency
- QR code generated client-side via locally hosted
qrcode.min.js— the secret never transits to an external QR service - 2FA is mandatory for all self-registered users (role: staff)
- First-run super-administrator may optionally skip during initial setup, but is prompted to enable immediately after
- Backup recovery codes not currently implemented — document your TOTP secret securely
Role-Based Access Control (RBAC)
| Role | Access Level |
|---|---|
| superadmin | Full platform access including Admin Portal (tenants, users, audit log, feature flags) |
| admin | Full church management access; cannot access Admin Portal |
| staff | Standard access; 2FA mandatory; permissions scoped by role |
| readonly | View-only access; cannot modify data |
The platform owner (admin@sermonassist.com) is permanently protected — this account cannot be deleted, disabled, or demoted by any action within the application, including by other super-admins. This is enforced by isProtectedOwner() with server-side guards on all user management actions.
4 Session Security
- Session fixation prevention:
session_regenerate_id(true)is called on every successful login, destroying the previous session ID - Idle timeout: Sessions expire after 8 hours of inactivity (
last_seentimestamp checked on every request) - Absolute timeout: Sessions expire after 30 days regardless of activity (
login_attimestamp enforced) - HttpOnly cookies: The session cookie is not accessible to JavaScript (
session.cookie_httponly = 1) - SameSite=Lax: Prevents cross-site request forgery via cookie submission
- Secure flag: Set automatically when the application is served over HTTPS
- Strict mode:
session.use_strict_mode = 1— prevents session ID fixation from uninitialized sessions - Only cookies:
session.use_only_cookies = 1— session IDs may not appear in URLs - Disabled users blocked: Disabled user accounts are refused at login time even with correct credentials and a valid session
5 Application Security
SQL Injection Prevention
Every database query in AI Church uses PDO prepared statements with parameterized queries. String interpolation into SQL is forbidden by convention. There are no raw SQL queries with user-supplied data anywhere in the codebase.
Cross-Site Scripting (XSS) Prevention
- All user-supplied content rendered in HTML is escaped via
h()→ PHP'shtmlspecialchars(ENT_QUOTES|ENT_SUBSTITUTE, 'UTF-8') - AI-generated content rendered as HTML is first sanitized via DOMPurify (locally hosted, no CDN) before being parsed by marked
- The
acEsc()client-side helper escapes values injected into JavaScript contexts - Content Security Policy (CSP) is set as both an HTTP header and a PHP fallback, preventing inline script execution except for intentional application code
CSRF Protection
- A per-session CSRF token is emitted as
window.CSRFin the page<head> - The global
fetch()is patched to automatically includeX-CSRF-Tokenon all non-GET requests - Every HTML form receives a hidden
csrffield (injected byendPage()) - Server-side validation uses
hash_equals()(timing-safe comparison) on every authenticated POST - CSRF validation is fail-closed — a missing or invalid token results in request rejection, never a silent pass
Error Handling
display_errors = 0is set at runtime — PHP errors never reach the browser or expose application internals- All database errors are caught and logged server-side without exposing schema details to users
6 Rate Limiting & Brute Force Prevention
AI Church implements a comprehensive rate-limiting subsystem using an in-database rate_limits table with server-side enforcement:
| Endpoint / Action | Limit | Window | Scope | Response on Limit |
|---|---|---|---|---|
| Login | 10 attempts | 15 minutes | IP address only | Redirect with err=locked; correct password also blocked |
| 2FA verification | 10 attempts | 15 minutes | IP address | Redirect with lockout message |
| 2FA setup confirmation | 12 attempts | 15 minutes | IP address | Redirect with lockout message |
| JSON API (all requests) | 240 requests | 1 minute | IP address | HTTP 429 Too Many Requests |
| JSON API (bad API key) | 20 attempts | 15 minutes | IP address | HTTP 429 — prevents key enumeration |
| Cron endpoint (bad token) | 15 attempts | 15 minutes | IP address | HTTP 429 |
IP-only scoping: Login rate limiting is intentionally scoped to IP address only — not to email address. This design prevents account enumeration (an attacker cannot determine which email addresses are registered by observing lockout behavior) and prevents denial-of-service attacks against known user accounts.
7 Network Security
TLS / Transport Security
- All outbound server-side connections (SMTP, Anthropic API, Twilio, ChMS integrations) use TLS with certificate verification enabled — self-signed certificates are rejected
- SMTP connections use STARTTLS or direct TLS/SSL based on the configured port
- CR/LF and NUL injection characters are stripped from all email addresses and subjects before SMTP transmission
HSTS
Strict-Transport-Security: max-age=31536000; includeSubDomains is set via .htaccess and as a PHP header fallback, instructing browsers to require HTTPS for all future visits.
8 File Upload Security
- Member photo uploads are validated with
getimagesize()— only valid image files pass; arbitrary file uploads are rejected - Uploaded files are stored in
uploads/members/with PHP execution disabled for that directory (viauploads/.htaccess:php_flag engine off) - An additional mod_rewrite rule in the root
.htaccessblocks any PHP file execution withinuploads/as a defense-in-depth measure uploads/index.phpcontains an empty file to prevent directory listing- File paths are not user-controllable — the server generates the storage filename
9 Supply Chain Security
Zero external CDN dependencies. Every JavaScript library, CSS framework, icon font, and web font used by AI Church is vendored locally in
assets/vendor/. No external script ever executes in a user's browser session.This completely eliminates the most common web supply-chain attack vector: a compromised CDN serving malicious JavaScript to millions of sites. Specifically:
- Chart.js, marked, DOMPurify, SheetJS, jsPDF, qrcode.js — all local copies in
assets/vendor/js/ - Font Awesome 6.5.1 — complete local copy (CSS + woff2 fonts) in
assets/vendor/fa/ - Inter variable font — self-hosted latin + latin-ext variants in
assets/vendor/fonts/ - Bootstrap 5.3 — inlined in the application's
getCssAndJs()function, no CDN - 2FA QR codes — generated client-side via local
qrcode.min.js; the TOTP secret never transits to an external QR service
External API calls (Anthropic, Twilio, ChMS platforms, Bible API) are server-side integrations, not browser-side script execution. They are made with the user's own credentials and are governed by the respective service's security posture.
10 Data Protection
Database
- The SQLite database file (
aichurch.db) is protected by.htaccesswithRequire all denied— it cannot be downloaded via the web - WAL and SHM journal files are also blocked
- Database encryption at rest is the responsibility of the host filesystem or disk-level encryption (e.g., LUKS on Linux, BitLocker on Windows Server)
- The
settingstable stores API keys. On your own server, these are as secure as your file system permissions
Secrets Management
- API keys (Anthropic, Twilio, Breeze, etc.) are stored in the SQLite
settingstable — never in code, environment variables, or configuration files committed to version control - The TOTP secret is stored in the
userstable, accessible only to authenticated super-admins - Auto-generated tokens (
cron_token,ics_feed_token,api_key) are cryptographically random, generated via PHP'srandom_bytes()
Sensitive File Protection
The following files are blocked from web access via .htaccess:
aichurch.db,*.db-wal,*.db-shm,*.sqlite— database files*.bak*,*.env,*.log,*.sh,*.py,*.docx— backup and configuration filesCLAUDE.md,DEPLOY.md— internal documentation- All dotfiles (
.git,.env,.htpasswd, editor swap files) — with an exception for.well-known/(required for ACME/SSL certificate issuance) deploy/,Instagram/,LinkedIn/,LEGAL-DOCUMENTATION/— private tooling and marketing assets
11 Infrastructure (Demo Instance)
The AI Church demo instance at aichurch.boreon.com is hosted on Infomaniak infrastructure in Geneva, Switzerland:
Swiss Data SovereigntyInfrastructure in Geneva under Swiss Federal Act on Data Protection (nFADP)
GDPR AdequacySwitzerland recognized by EU Commission as providing adequate data protection
No US Cloud ProvidersInfomaniak does not use AWS, Azure, or Google Cloud — 100% European infrastructure
Green EnergyInfomaniak data centers run on 100% renewable Swiss hydroelectric power
12 Security Headers
AI Church sets the following security headers on all responses, via both .htaccess and PHP-level fallbacks (so they apply even if mod_headers is unavailable):
| Header | Value | Purpose |
|---|---|---|
Content-Security-Policy | default-src 'self'; script-src 'self' 'unsafe-inline'; frame-src 'self' youtube.com facebook.com | Prevents unauthorized script loading; restricts framing |
Strict-Transport-Security | max-age=31536000; includeSubDomains | Forces HTTPS for 1 year; eliminates SSL stripping attacks |
X-Frame-Options | SAMEORIGIN | Prevents clickjacking via iframe embedding |
X-Content-Type-Options | nosniff | Prevents MIME type sniffing attacks |
Referrer-Policy | strict-origin-when-cross-origin | Limits referrer information exposure |
Permissions-Policy | Geolocation, microphone, camera, payment, USB all denied | Prevents permission escalation attacks |
Cross-Origin-Opener-Policy | same-origin | Prevents cross-origin window attacks (Spectre) |
Cross-Origin-Resource-Policy | same-site | Prevents cross-site resource loading attacks |
X-Powered-By | [removed] | Prevents technology fingerprinting |
13 Vulnerability Disclosure
Responsible Disclosure Program
We welcome security researchers, ethical hackers, and community members who responsibly report vulnerabilities. Churches depend on this software — every responsible disclosure helps protect congregations worldwide.
If you discover a security vulnerability in AI Church, please:
- Do not publicly disclose the vulnerability before we have had a chance to patch it
- Do not exploit the vulnerability beyond what is necessary to demonstrate it
- Do not access, modify, or destroy church member data
- Include a clear description of the vulnerability, steps to reproduce, and the potential impact
Report to: admin@sermonassistant.ch
Subject line: SECURITY: [brief description]
Response time: We will acknowledge within 48 hours and provide a fix timeline within 7 days.
Recognition: We publicly credit responsible disclosers (with their permission) in our security changelog.
Subject line: SECURITY: [brief description]
Response time: We will acknowledge within 48 hours and provide a fix timeline within 7 days.
Recognition: We publicly credit responsible disclosers (with their permission) in our security changelog.
Unauthorized probing, scanning, or attempting to exploit the production demo instance (
aichurch.boreon.com) without prior written permission constitutes unauthorized computer access under the Computer Fraud and Abuse Act (18 U.S.C. § 1030) and equivalent international law. Please test against a local self-hosted instance.14 Security Changelog
Major security changes by version:
| Version | Date | Security Changes |
|---|---|---|
| v3.9 | June 2026 | Rate limiting subsystem (IP-only login, 2FA, API, cron); boot hardening (display_errors=0, session strict mode); 8h idle + 30d absolute session timeout; PHP-level security header fallback; .htaccess CSP, HSTS, COOP/CORP; Options -Indexes; dotfile blocking; protected owner permanence; session regeneration on every login |
| v3.8 | June 2026 | Leader Pipeline + Streaming Hub with proper RBAC; upload PHP-exec block; audit log for all admin actions; disabled user enforcement at login |
| v3.4 | June 2026 | All CDN dependencies removed and vendored locally (zero supply chain risk); 2FA QR generated locally (TOTP secret no longer sent to external QR service) |
| v3.2 | June 2026 | Passed 18-finding adversarial review: CSRF fail-closed with hash_equals; XSS prevention via acEsc(); RBAC enforcement; SMTP injection prevention; TLS cert verification; default credential removal from login form; session hardening |