Information Security Policy

Now by Coconut Tree

Version 1.0 — April 2026 — Classification: Confidential

1. Purpose and Scope

This policy defines the information security practices for Now by Coconut Tree ("Now App"), a personal lifestyle and financial management application. It covers all systems, data, and processes involved in collecting, processing, storing, and transmitting consumer data, with particular focus on financial data accessed through the Plaid API.

This policy applies to all personnel with access to production systems, code repositories, and consumer data.

2. Governance and Risk Management

2.1 Security Responsibility

Information security is managed by the application owner, who serves as the designated security officer responsible for:

• Maintaining and enforcing this security policy
• Monitoring for security incidents and vulnerabilities
• Reviewing and updating security practices quarterly
• Responding to security inquiries from partners (including Plaid)

2.2 Risk Assessment

Security risks are assessed based on data sensitivity classification:

Classification	Data Types	Controls
Critical	Plaid access tokens, bank credentials	Server-side only, AES-256-GCM encrypted at rest, never transmitted to client
High	Financial transactions, debts, court dates, health data	Client-side AES-256-GCM encryption, PIN-protected access, auto-purge on sign-out
Medium	Tasks, calendar events, goals, habits	Supabase RLS, authenticated access only
Low	UI preferences, theme settings	Standard localStorage

3. Identity and Access Management

3.1 Consumer Authentication

• Primary authentication: Google OAuth 2.0 via Supabase Auth. No passwords stored by the application.
• Secondary authentication: Mandatory 4-digit PIN required for all users, created during onboarding. PIN stored as salted SHA-256 hash with user-specific salt.
• PIN recovery: Two security questions with hashed answers. Alternative: Google re-authentication to reset.
• Brute-force protection: 5 failed PIN attempts triggers 30-second lockout. Failed attempts logged in audit trail.
• Session management: 5-minute inactivity timeout locks the entire application, requiring PIN re-entry.

3.2 Production System Access

• Production hosting on Render with dashboard-based access control
• No direct SSH access to production servers
• Environment variables (API keys, encryption keys) managed through Render dashboard, not stored in code
• Code repository access controlled via GitHub permissions

3.3 Plaid API Access

• Plaid client credentials stored as environment variables on the production server
• All Plaid API calls proxied through the application server — client never communicates directly with Plaid
• Consumer access tokens stored exclusively server-side in AES-256-GCM encrypted files
• Client stores only non-sensitive item reference IDs (no tokens, no credentials)
• JWT validation on all Plaid proxy endpoints: claimed user_id verified against Supabase session token
• Rate limiting: maximum 10 Plaid API requests per user per minute

4. Data Encryption

4.1 Encryption in Transit

• All client-server communication over HTTPS with TLS 1.2+ (enforced by Render)
• All Supabase API calls over HTTPS
• All Plaid API calls over HTTPS
• No unencrypted connections in production

4.2 Encryption at Rest — Client Side

• Algorithm: AES-256-GCM via Web Crypto API
• Key derivation: PBKDF2 (100,000 iterations, SHA-256) from the user's Supabase session token
• Encrypted keys: budgetRecovery, budgetEntries, budgetGoals, budgetDebts, budgetRecurring, budgetEnvelopes, plaidAccounts (reference only), supplementLogs, supplementSymptoms, cycleData
• IV handling: Random 12-byte IV generated per encryption operation, prepended to ciphertext
• Non-sensitive data (UI preferences, task lists) stored as plaintext JSON in localStorage

4.3 Encryption at Rest — Server Side

• Algorithm: AES-256-GCM via OpenSSL
• Key derivation: SHA-256 hash of APP_ENCRYPTION_KEY environment variable
• Encrypted files: .plaid_tokens.enc (Plaid access tokens), .pin_hashes.enc (PIN verification hashes)
• Encrypted files excluded from version control via .gitignore

5. Infrastructure and Network Security

5.1 Hosting

• Application hosted on Render (render.com) with automatic TLS certificate management
• Database hosted on Supabase with Row Level Security (RLS) enforced
• No self-managed servers or infrastructure

5.2 API Security

• CSRF protection: All POST requests to API endpoints require X-Requested-With header; requests without it are rejected with HTTP 403
• Content Security Policy: Strict CSP headers on all HTML responses restricting script sources, connection endpoints, and embed capabilities
• Input validation: All user-provided content sanitized via escapeHtml() before rendering. No eval() or dynamic code execution.
• Rate limiting: In-memory sliding window rate limiter on financial API endpoints (10 requests/minute/user)

5.3 Database Security

• Supabase Row Level Security (RLS) policies enforce that users can only SELECT, INSERT, UPDATE, and DELETE their own rows
• RLS policies applied to: user_data, user_profiles, partnerships, shared_content tables
• Supabase anon key is publishable (by design); all data access governed by RLS + JWT

6. Data Lifecycle Management

6.1 Data Collection and Consent

• Three-tier consent system with timestamped acceptance:
  • General terms: Required on first sign-in (covers basic app usage, AI, sync)
  • Financial data consent: Required before first budget widget access (covers Plaid, financial data, Lifeline)
  • Health data consent: Required before first cycle tracker access (covers health data)
• Privacy policy publicly available at /privacy.html
• Application restricted to users 18 years and older

6.2 Data Retention

• Consumer data retained as long as the user maintains an active account
• Financial data purged from client (localStorage) on every sign-out
• Clipboard auto-cleared 60 seconds after copying sensitive content (legal templates, negotiation scripts)
• Audit log capped at 100 entries (rolling)

6.3 Data Deletion

• Users can permanently delete all data from the application settings
• Users can export all data as JSON before deletion
• Users can disconnect bank accounts, which removes the stored access token from the server
• Deletion clears: localStorage, Supabase user_data row, and all associated records

7. Audit and Monitoring

7.1 Audit Logging

Security-relevant events are logged with timestamps (events only, never data content):

Event	Trigger
sign_in	User authenticates via Google OAuth
sign_out	User signs out
pin_created	New PIN set with security questions
pin_unlock	Successful PIN entry
pin_lockout	5 consecutive failed PIN attempts
pin_reset	PIN reset via security questions or re-authentication
app_locked	5-minute inactivity timeout triggered
data_export	User exports their data
data_delete_all	User deletes all their data
bank_connected	Plaid bank account linked
bank_sync	Transaction import from Plaid

7.2 Error Monitoring

• Global error boundary catches unhandled JavaScript errors
• Error toasts shown to user for sync failures, API errors, and connection issues
• Server-side errors logged to stderr

8. Vulnerability Management

8.1 Application Security Controls

• Content Security Policy (CSP) headers prevent XSS attacks
• CSRF protection via custom request headers
• All user input sanitized before rendering (escapeHtml)
• No third-party JavaScript dependencies in production (vanilla JS, no npm packages)
• No eval(), innerHTML with unsanitized content, or dynamic script injection
• Path traversal prevention on static file serving

8.2 Dependency Management

• Production application has zero npm dependencies — all code is first-party vanilla JavaScript
• Third-party scripts limited to: Supabase client library (CDN), Plaid Link SDK (CDN)
• CSP headers restrict which external scripts can execute

9. Incident Response

In the event of a suspected security incident:

1. Immediately revoke affected Plaid access tokens via the Plaid dashboard
2. Rotate APP_ENCRYPTION_KEY and PLAID_SECRET environment variables
3. Notify affected users via email within 72 hours
4. Notify Plaid's security team
5. Document the incident, root cause, and remediation steps
6. Review and update this policy as needed

10. Policy Review

This policy is reviewed and updated quarterly, or immediately following any security incident or significant infrastructure change. All updates are versioned and dated.