Effective version: 2026-05-02
Security Overview
Conexion Platform — Community Intelligence LLC
Last Updated: 2026-05-02
DISCLAIMER: This document is a template and should be reviewed before distribution to clients. Verify all claims against the current codebase.
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 | Encrypted connections (SSL), pgvector for AI embeddings |
| Cache | Redis 7 | Password-protected, TLS in production, internal network only |
| Task Queue | Celery 5.5 | Async processing with soft/hard timeouts |
| Web Server | Gunicorn | Non-root process, resource limits |
| Reverse Proxy | Caddy or Cloud Load Balancer | Automatic TLS, HTTP/2 |
2. Authentication and Access Control
User Authentication
| Control | Implementation |
|---|---|
| Password hashing | PBKDF2-SHA256 with Django's default 870,000 iterations |
| Password policy | Minimum length, 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 |
|---|---|
| Administrator | 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
- 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 cloud secret managers (GCP Secret Manager, AWS Secrets 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 connections | SSL required in production |
| Backup uploads | HTTPS to S3-compatible storage |
| 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
All data modifications are logged with:
| Field | Description |
|---|---|
| User | Who made the change (authenticated user) |
| Timestamp | When the change occurred (UTC) |
| IP Address | Source IP of the request |
| Action | Create, update, or delete |
| Object | Which record was changed (model + ID) |
| Changes | JSON diff of before/after field values |
| Request ID | Correlation ID for log 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, verify, disable, reset) logged
- Session creation and revocation logged
- 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 | Weekly | Per storage policy | Pre-encrypted before upload |
Recovery Capabilities
- Automated restore scripts with integrity verification
- Database point-in-time restore (RDS/Cloud SQL — managed hosting)
- Documented restore procedures for all deployment tiers
- Health check endpoints for automated monitoring (
/readyz/checks database, cache, and worker connectivity)
Recovery Objectives
| Metric | Tier 1 (VPS) | Tier 2 (AWS/GCP) |
|---|---|---|
| Recovery Point Objective (RPO) | Up to 24 hours | Up to 24 hours (continuous for RDS) |
| Recovery Time Objective (RTO) | < 4 hours | < 1 hour |
7. Application Security
Built-in Protections
| Threat | Mitigation |
|---|---|
| SQL Injection | Django ORM parameterized queries; no raw SQL in application code |
| 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 | File type validation; upload size limits (50MB); 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
- 80% test coverage threshold 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 |
| Read-only filesystem | Where applicable |
| 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
- Sentry error monitoring has PII collection explicitly disabled (
send_default_pii=False)
Cloud Provider Certifications
| Provider | Certifications |
|---|---|
| Google Cloud Platform | SOC 1/2/3, ISO 27001/17/18, HIPAA BAA available, FedRAMP |
| Amazon Web Services | SOC 1/2/3, ISO 27001, HIPAA BAA available, FedRAMP |
| DigitalOcean | SOC 2 Type II, ISO 27001 |
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 (60 days for HIPAA breach notification)
- 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.io