Security Practices

Effective Date: February 2026 | Last Updated: February 2026

1. Our Security Philosophy

We follow a defense-in-depth approach with multiple layers of security. Health data deserves the highest protection standards, and we continuously improve our security posture.

2. Data Encryption

2.1 Encryption in Transit

• Protocol: TLS 1.3 for all connections
• Certificate: Valid SSL certificates from trusted authorities
• HSTS: HTTP Strict Transport Security enforced
• API: All API communications over HTTPS

2.2 Encryption at Rest

2.3 End-to-End Encryption (E2EE)

Professional-client messaging uses state-of-the-art E2EE:

• Algorithm: Double Ratchet (Signal Protocol family)
• Implementation: Olm/Vodozemac by Matrix.org
• Key Exchange: Curve25519
• Message Encryption: AES-256
• Forward Secrecy: Compromised keys cannot decrypt past messages
• Security Audit: Implementation audited by Least Authority

What this means: Messages are encrypted on your device before transmission. Not even Laxhar Tech can read message content.

3. Contraindication Safety Engine

Swasth includes a contraindication engine that evaluates health contexts against exercises, foods, and activities to provide safety flags:

• Pre-computed markings: Stored in read-only SQLite databases — no Protected Health Information (PHI) is stored in these reference databases
• Client-side evaluation: Health context evaluation happens in the browser (client-side) — sensitive health data does not leave your device for contraindication checks
• Reference data only: The contraindication databases contain only general medical rules and safety flags, not user-specific health data
• Version-controlled: Databases are versioned and updated through app releases with cache-busting mechanisms

4. Offline Data Security

4.1 Browser SQLite Databases

Swasth uses SQLite databases in the browser for offline access to system reference data:

• These databases contain only system reference data (exercises, ingredients, medical conditions, contraindication rules) — not user health data
• Delivered via WASM (WebAssembly) for secure in-browser execution
• Version-based cache invalidation ensures users receive updated data

4.2 RxDB (IndexedDB)

User health logs are stored locally in RxDB (built on IndexedDB) for offline-first access:

• Data is encrypted at rest by the browser's built-in IndexedDB encryption
• Bidirectional sync with the server occurs over encrypted connections (TLS)
• Local data is accessible only to the Swasth application origin

4.3 Service Worker Cache

• Service worker manages caching of static assets and SQLite databases
• StaleWhileRevalidate strategy with version-based invalidation for database files
• Cache is isolated per origin and cannot be accessed by other websites

5. Authentication Security

5.1 OAuth 2.0 with PKCE

• Modern OAuth 2.0 authentication flow
• PKCE (Proof Key for Code Exchange) prevents interception attacks
• No passwords stored in Swasth databases
• Secure token management

5.2 Session Security

• Secure, HttpOnly session cookies
• Automatic session expiration
• Session invalidation on logout
• Concurrent session management

5.3 Device Security

• Unique device identifiers for E2EE
• Device registration for key management
• Suspicious device detection

6. Access Controls

6.1 Role-Based Access

• Users access only their own data
• Professionals access client data only with consent
• Family members access only shared data
• Admin access strictly controlled and logged

6.2 Data Sharing Controls

• Granular privacy settings per data category
• Professional access requires active relationship
• Access revoked immediately on relationship end
• Client controls what professionals see

7. Rate Limiting & DDoS Protection

• API rate limiting to prevent abuse
• Enhanced rate limiting on sensitive endpoints:
  • Key upload: 10 requests/minute
  • Key query: 30 requests/minute
  • Key claim: 20 requests/minute
• DDoS protection at infrastructure level
• Automatic blocking of suspicious patterns

8. Audit Logging

8.1 What We Log

• Authentication events (login, logout, failures)
• Medical document access
• Sensitive data access by professionals
• Account changes
• E2EE key operations

8.2 Log Security

• Logs stored securely with restricted access
• Tamper-evident logging
• Retention per compliance requirements (7 years)
• Regular log review for anomalies

9. Vulnerability Management

9.1 Security Testing

• Regular security assessments
• Dependency vulnerability scanning
• Code security reviews
• Penetration testing (periodic)

9.2 Dependency Management

• Regular updates of dependencies
• Automated vulnerability alerts
• Quick patching of critical vulnerabilities

10. Infrastructure Security

10.1 Cloud Security

• Secure cloud infrastructure providers
• Network isolation and firewalls
• Encrypted data storage
• Regular security audits

10.2 Backup & Recovery

• Regular automated backups
• Encrypted backup storage
• Disaster recovery procedures
• Recovery testing

11. Secure Development

11.1 Development Practices

• Security-focused code reviews
• Input validation and sanitization
• Protection against OWASP Top 10 vulnerabilities
• Secure coding guidelines

11.2 Third-Party Security

• Security assessment of integrations
• Data processing agreements with vendors
• Regular vendor security reviews

12. Incident Response

12.1 Our Commitment

In the event of a security incident:

• Immediate containment and investigation
• Notification within 72 hours (as required by DPDPA)
• Clear communication about impact and remediation
• Post-incident analysis and improvements

12.2 What You'll Be Told

• Nature of the incident
• Data potentially affected
• Steps we're taking
• Actions you should take
• Contact for questions

13. Your Role in Security

Help us keep your data secure:

• Use strong, unique passwords for your OAuth account
• Enable two-factor authentication where available
• Keep your devices and browsers updated
• Be cautious of phishing attempts
• Log out from shared devices
• Report suspicious activity to us
• Don't share your E2EE device with others

14. Security Contact

To report security vulnerabilities or concerns:

• Security Team: [email protected]
• General Support: [email protected]

We appreciate responsible disclosure. Please give us reasonable time to address issues before public disclosure.

15. Compliance & Standards

Our security practices align with:

• DPDPA 2023 (Digital Personal Data Protection Act) - Indian data protection law
• IT Act 2000 and SPDI Rules - Sensitive Personal Data protection
• Industry security best practices - Healthcare-grade encryption and access controls
• OWASP security guidelines - Protection against top vulnerabilities
• ISO 27001 principles - Information security management best practices

15.1 Healthcare-Grade Security

We implement healthcare-grade security measures including:

• AES-256 encryption (same standard used by banks and healthcare providers globally)
• End-to-end encryption for sensitive communications
• Comprehensive audit logging for accountability
• Role-based access controls with granular permissions
• Regular security assessments and vulnerability management

15.2 Regulatory Note

Important: Swasth is an Indian company operating under Indian law. We are not subject to HIPAA (Health Insurance Portability and Accountability Act), which applies only to US healthcare entities. However, our security practices are designed to meet or exceed the standards expected for health data protection globally.