Security at SLIM

No Code Storage

SLIM does not collect or store lockbox access codes. Your codes remain with you and on the physical lockbox — never in our servers, databases, or backups. There is no code field in the application. This is a deliberate architectural decision: by never possessing codes, we significantly reduce the most severe category of breach risk.

Data Encryption

In transit. All data transmitted between your browser and SLIM is encrypted using TLS 1.2 or higher. HTTPS is enforced on every page and API endpoint with HSTS headers.

At rest. The database is encrypted at rest using the hosting provider’s built-in encryption. Sensitive data fields use additional application-layer encryption (AES-256-GCM) with keys managed through AWS Key Management Service (KMS) in the ca-central-1 (Canada) region. Encryption keys are automatically rotated.

Data Residency and Sovereignty

Encryption keys are configured to be stored and managed in AWS ca-central-1 (Montreal). The database is hosted by Supabase with encrypted connections. The application is hosted on Vercel. Data may be processed in Canada and the United States. For full details on cross-border processing, see our Privacy Policy.

Data Isolation

Every team’s data is isolated at the database level using PostgreSQL Row Level Security (RLS) policies. This is enforced by the database engine itself — not just application-level filtering. Even if a bug existed in application code, the database would reject unauthorized cross-team data access. RLS policies are applied to all tables containing customer data. No other SLIM user or team is able to see or access your data through the Service.

Access Control and Permissions

SLIM uses role-based access control with four distinct roles:

• Solo Agent — manages their own lockboxes
• Team Leader — full visibility and control across the team
• Team Admin — team-wide visibility and management, no billing access
• Team Agent — sees only lockboxes they created or are assigned to

Permissions are enforced at both the API layer and the database layer. No role can be escalated by a user without authorization from a Team Leader.

Authentication Security

• Passwords are hashed using bcrypt with automatically generated salts — we never store plaintext passwords
• CAPTCHA verification is required after 3 failed login attempts
• Accounts are locked for 15 minutes after 5 failed attempts
• Login attempt tracking detects and logs brute-force patterns
• Sessions use secure, HttpOnly, SameSite cookies that cannot be accessed by client-side scripts
• Password reset tokens expire after 15 minutes (deliberately shorter than the industry-standard 1 hour)
• Email verification is required for all new accounts
• Phone number verification via a third-party identity verification service

Immutable Audit Trail

Every action on every lockbox is logged permanently: who performed the action, what changed, and when. The audit trail is designed to be immutable at the database level — a database trigger is configured to prevent modification or deletion of audit records, including by administrators.

Audit trail records include the action type, the user who performed it, a timestamp, and before/after state. IP addresses associated with actions are stored in pseudonymized (hashed) form using a one-way cryptographic function for privacy compliance.

Input Validation and Sanitization

All user input is validated server-side using strict schema validation before processing. This protects against injection attacks, malformed data, and unexpected input. File uploads are processed through a sanitization pipeline that strips EXIF metadata (including GPS coordinates) from photos before storage — preventing location data leakage even if storage were compromised.

Secrets Management

Application secrets (API keys, signing keys, encryption keys) are stored in AWS Secrets Manager in the ca-central-1 (Canada) region — not in environment variables or source code. Access is restricted to the application runtime. Every AWS SDK call explicitly specifies the Canadian region to prevent accidental routing through non-Canadian infrastructure.

Rate Limiting

The Service enforces rate limits on sensitive operations including login attempts, password resets, and API requests. Rate limiting is applied per-user and per-IP to prevent abuse while allowing normal usage.

Infrastructure

Breach Response

In the event of a security incident, we follow a defined incident response process: detect and contain, assess scope and impact, notify affected users and the Office of the Privacy Commissioner of Canada where required by law (within the timeframes mandated by PIPEDA), remediate the vulnerability, and conduct a post-incident review. We maintain breach records for at least 24 months as required by Canadian privacy regulations. For full details, see the Breach Notification section of our Privacy Policy.

Security Review

SLIM’s security architecture has been subject to internal review and automated security analysis covering encryption design, database isolation patterns, authentication mechanisms, and key management. Findings were remediated before production deployment.

Compliance

• PIPEDA — Aligned with the Personal Information Protection and Electronic Documents Act requirements for breach notification, data handling, and cross-border transfers
• Data minimization — We do not collect or store lockbox access codes; we collect only the data necessary to provide the Service
• Cookie consent — Analytics and measurement tools load only after explicit user consent
• Dependency security — All software dependencies use exact version pinning and are regularly audited for known vulnerabilities

Vulnerability Disclosure

If you discover a security vulnerability in SLIM, please report it responsibly to security@getslim.app. We ask that you:

• Do not publicly disclose the vulnerability before we have had a reasonable opportunity to address it
• Do not access or modify other users’ data
• Provide sufficient detail for us to reproduce and fix the issue

We will acknowledge receipt within 48 hours and aim to provide an initial assessment within 5 business days.

Questions

Questions about our security practices? Contact security@getslim.app.