Effective version: 2026-07-24
Security Overview
Conexion Platform — Community Intelligence LLC
Last Updated: 2026-07-24
1. Architecture
Single-Tenant Isolation
Every Client deployment runs on a dedicated, isolated database. There is no shared data storage between Clients. This eliminates the risk of cross-tenant data leakage that exists in multi-tenant architectures.
- Each deployment has its own PostgreSQL database instance
- Each deployment has its own application server(s)
- Each deployment has its own Redis cache instance
- Each deployment has its own file storage (S3 bucket, GCS bucket, or local volume)
- Each deployment has its own encryption key
Technology Stack
| Component | Technology | Security Relevance |
|---|---|---|
| Web Framework | Django 6.0 | Mature framework with built-in CSRF, XSS, SQL injection protections |
| API Framework | Django REST Framework | Token-based auth, rate limiting, permissions system |
| Database | PostgreSQL 17 (pgvector) | Confined to an internal-only network, never publicly exposed |
| Cache | Redis 7 | Password-protected, internal-only network |
| Task Queue | Celery 5.4 | Async processing with soft/hard timeouts |
| Web Server | Gunicorn | Non-root process, resource limits |
| Reverse Proxy | Caddy | Automatic TLS (Let's Encrypt), HTTP/2 |
2. Authentication and Access Control
User Authentication
| Control | Implementation |
|---|---|
| Password hashing | PBKDF2-SHA256 with Django's default 1,200,000 iterations |
| Password policy | Minimum length (12 characters), common password blocklist, no username similarity, no all-numeric |
| Multi-factor authentication | TOTP-based (RFC 6238), configurable per organization, with 10 single-use recovery codes |
| Brute-force protection | Account lockout after 5 failed attempts for 1 hour (django-axes) |
| Session management | 8-hour timeout, browser-close expiration, HttpOnly + Secure + SameSite cookies |
| API authentication | JWT tokens with 30-minute access token, 1-day refresh token, automatic rotation, blacklist-after-rotation |
| User provisioning | Invite-only registration (no public self-signup) |
| MFA enforcement | Organization-level setting forces MFA setup before data access |
Role-Based Access Control
Five permission levels control data access:
| Role | Scope |
|---|---|
| Admin | Full platform access, user management, system configuration |
| Director | Organization-wide data access, reporting, staff management |
| Grants Manager | Grant pipeline, funder data, grant reports |
| Finance Manager | Financial data, budgets, expenses, time allocations |
| Program Staff | Assigned program data, participant records, service delivery |
3. Data Encryption
Encryption at Rest
Sensitive fields are encrypted at the application level using Fernet symmetric encryption (AES-128-CBC with HMAC-SHA256 for integrity):
- Participant date of birth
- Participant address (street, city, state, ZIP)
- Participant veteran status
- Participant disability status
- Participant immigration status
- Participant refugee/asylee status
- Household (account) address fields and notes
- Webhook endpoint URLs and signing secrets
- Third-party integration credentials (API keys, OAuth tokens)
- Email account credentials (IMAP/SMTP passwords)
- AI provider API keys
Encryption keys are managed through environment variables and stored in GCP Secret Manager for managed hosting deployments.
Encryption in Transit
| Channel | Protection |
|---|---|
| Web traffic | TLS 1.2+ (HTTPS enforced) |
| HSTS | 1-year duration, includeSubdomains, preload-ready |
| Database and cache traffic | Confined to an internal-only container network on the host; never traverses a public network |
| Backup uploads | HTTPS to Google Cloud Storage (files GPG-encrypted before upload) |
| API calls to AI providers | HTTPS (TLS 1.2+) |
Backup Encryption
- Database and media backups encrypted with AES-256 via GPG symmetric encryption
- SHA-256 integrity checksums generated and verified on each backup
- Backup files created with restrictive permissions (0600 — owner-only)
- Encryption key separate from application encryption key
4. Network Security
HTTP Security Headers
| Header | Value | Purpose |
|---|---|---|
| Content-Security-Policy | default-src 'self'; nonce-based scripts | Prevents XSS and code injection |
| X-Frame-Options | DENY | Prevents clickjacking |
| X-Content-Type-Options | nosniff | Prevents MIME-type sniffing |
| Referrer-Policy | strict-origin-when-cross-origin | Controls referrer information leakage |
| Permissions-Policy | Disables: geolocation, microphone, camera, payment, USB | Restricts browser API access |
| Strict-Transport-Security | 1-year, includeSubdomains, preload | Forces HTTPS for all connections |
| Cross-Origin-Opener-Policy | same-origin | Prevents cross-origin window attacks |
API Rate Limiting
| Endpoint Type | Limit |
|---|---|
| Unauthenticated requests | 100/hour |
| Authenticated requests | 1,000/hour |
| Login/token endpoint | 10/hour |
CORS and CSRF
- CORS allowed origins explicitly configured (no wildcards in production)
- CSRF tokens required on all state-changing requests
- CSRF cookie set with HttpOnly flag
Infrastructure Network
- Database bound to private/internal network (not publicly accessible)
- Redis bound to private/internal network
- Backend services communicate over internal Docker network
- Only the web server and reverse proxy are publicly accessible
5. Audit Logging
The Platform maintains an audit trail of security-relevant activity:
| Event | Details recorded |
|---|---|
| Authentication (login, logout, failed attempts) | User, timestamp (UTC), IP address |
| Access to participant-related records (reads) | User, timestamp, IP address, endpoint |
| Terms-of-service acceptance | User, timestamp, version accepted |
| Data changes by automated workflows | Actor, timestamp, affected record (model + ID), change summary with sensitive values redacted |
Application logs additionally carry a per-request correlation ID for tracing.
Audit logs are:
- Append-only (no modification or deletion through the application)
- Indexed for efficient querying
- Retained for the duration of the Client's subscription
- Included in encrypted backups
Security Event Logging
In addition to data audit logs:
- Failed login attempts logged with IP address and username (django-axes)
- MFA events (setup, disable, recovery-code regeneration) logged
- Logins and logouts recorded in the audit log
- API authentication failures logged
6. Backup and Disaster Recovery
Backup Schedule
| Type | Frequency | Retention | Encryption |
|---|---|---|---|
| Database | Daily (2:00 AM) | 14 days (configurable) | AES-256 GPG |
| Media/files | Daily | 7 days (configurable) | AES-256 GPG |
| Off-site sync | Daily | Per storage policy | Pre-encrypted before upload |
Recovery Capabilities
- Automated restore scripts with integrity verification
- Documented restore procedures for all deployment tiers
- Health check endpoints for automated monitoring (
/readyz/checks database, cache, and worker connectivity)
Recovery Objectives
| Metric | Current deployment |
|---|---|
| Recovery Point Objective (RPO) | Up to 24 hours |
| Recovery Time Objective (RTO) | < 4 hours |
7. Application Security
Built-in Protections
| Threat | Mitigation |
|---|---|
| SQL Injection | Django ORM parameterized queries; the natural-language analytics feature executes only validated, SELECT-only queries against dedicated reporting views under a restricted read-only database role |
| Cross-Site Scripting (XSS) | Django template auto-escaping; Content Security Policy; nh3 HTML sanitization |
| Cross-Site Request Forgery (CSRF) | CSRF tokens on all forms; HttpOnly CSRF cookie |
| Clickjacking | X-Frame-Options: DENY |
| Session Hijacking | HttpOnly + Secure + SameSite cookies; session rotation on login |
| Brute Force | Account lockout (django-axes); rate limiting; MFA |
| Insecure File Upload | Content-sniffed file type validation; upload size limits (25MB); separate storage backend |
| Insecure Dependencies | Automated dependency scanning in CI; Bandit security linter |
Development Security Practices
- Pre-commit hooks enforce code formatting and linting
- Ruff linter checks for security anti-patterns
- Bandit static analysis for Python security issues
- Coverage-gated automated test suite (unit, integration, and end-to-end) enforced in CI
- No secrets in source code (environment variables for all credentials)
- Playwright end-to-end testing for critical user flows
8. Container Security
All production containers enforce:
| Control | Implementation |
|---|---|
| Non-root execution | All services run as non-root users |
| No new privileges | no-new-privileges: true security option |
| Resource limits | CPU and memory limits per container |
| Health checks | Database and Redis verified before accepting traffic |
| Internal networking | Backend services on internal-only Docker network |
9. Third-Party Security
AI Provider Data Handling
When AI features are used:
- Data is sent over HTTPS to Anthropic or Google Vertex AI APIs
- Enterprise API terms prohibit using customer data for model training
- No persistent storage of prompts by AI providers (per API terms)
- AI conversation history stored in the Client's own database
- Third-party error tracking is disabled in the current deployment; if enabled, PII collection is explicitly turned off (
send_default_pii=False)
Cloud Provider Certifications
| Provider | Certifications |
|---|---|
| Google Cloud Platform | SOC 1/2/3, ISO 27001/17/18, HIPAA BAA (signed), FedRAMP |
10. Compliance Support
The Platform includes a built-in compliance tracking module supporting:
- Multiple regulatory frameworks (HIPAA, SOC 2, GDPR, custom)
- Requirement status tracking with responsibility assignments
- Risk assessment documentation with severity levels
- Security incident reporting with breach notification workflow
- Staff compliance training tracking
- Business Associate Agreement management with expiration alerts
- Review scheduling and due date reminders
11. Monitoring and Incident Response
Uptime Monitoring
/health/— Liveness probe (process running)/readyz/— Readiness probe (database + cache + worker connectivity)- Optional Uptime Kuma integration for external monitoring and alerting
Incident Response
- Detection via audit logs, monitoring alerts, or user reports
- Containment within 4 hours of detection
- Client notification within 72 hours (for breaches of unsecured PHI: without unreasonable delay, no later than 10 business days — see the BAA)
- Investigation and root cause analysis
- Remediation and prevention measures
- Post-incident report within 30 days
12. Contact
For security questions or to report a vulnerability:
Email: security@communityintelligence.co