Security

Security

Effective Date: March 2026 Last Updated: March 2026

At SoneaLabs, we understand that import-export businesses entrust us with sensitive trade and financial data. Security is embedded into every layer of the Tijara platform. This document describes the technical controls, organizational practices, and infrastructure decisions that protect your data.

SoneaLabs is an independently operated brand based in Mumbai, India, building and operating the Tijara platform.

1. Infrastructure and Hosting

1.1 Cloud Architecture

Tijara is built on a modern cloud-native architecture:

1.2 Data Residency

Your data is stored in Supabase-managed PostgreSQL databases hosted on Amazon Web Services (AWS) infrastructure. Database backups are maintained by Supabase within the same cloud region.

1.3 Infrastructure Security Inheritance

We inherit security controls from our infrastructure providers:

• Supabase: SOC 2 Type II certified. PostgreSQL databases run on dedicated instances with automated backups, point-in-time recovery, and encryption at rest.
• Vercel: SOC 2 Type II certified. Application layer runs in isolated serverless environments with automatic scaling and DDoS protection.
• AWS (underlying Supabase): SOC 2, ISO 27001, ISO 27017, ISO 27018 certified. Physical data center security, redundant power, and network controls.

2. Data Encryption

2.1 Encryption in Transit

All data transmitted between your browser and the Tijara platform is encrypted using TLS 1.2 or higher. This applies to:

• All web application traffic (HTTPS enforced, HTTP requests are automatically redirected)
• API requests between the application and the database
• File uploads and downloads
• WebSocket connections for real-time updates

We enforce HTTP Strict Transport Security (HSTS) headers to prevent protocol downgrade attacks.

2.2 Encryption at Rest

• Database: All data at rest in the PostgreSQL database is encrypted using AES-256 encryption provided by the underlying AWS infrastructure (AWS RDS encryption).
• File Storage: Uploaded documents are stored in Supabase Storage, which uses server-side encryption at rest.
• Backups: Database backups are encrypted using the same encryption standards as the primary database.

2.3 Application-Level Encryption

Sensitive financial data receives an additional layer of application-level encryption beyond the infrastructure encryption:

• Bank details (account numbers, IBANs, SWIFT/BIC codes) stored for contacts are encrypted using AES-256-GCM with per-record initialization vectors (IVs) and key identifiers (KIDs).
• Encryption keys are managed separately from the encrypted data.
• Bank details are decrypted only at the application layer when requested by an authorized user within the same organization.

3. Authentication and Access Control

3.1 User Authentication

• User authentication is managed by Supabase Auth, which provides industry-standard session-based authentication.
• Passwords are hashed using bcrypt with a minimum cost factor, ensuring they cannot be reversed even if the database is compromised.
• Sessions are managed via secure, HttpOnly, SameSite cookies with configurable expiry.
• We support email-based password reset with time-limited tokens.

3.2 Row-Level Security (RLS)

All database tables are protected by PostgreSQL Row-Level Security policies. This means:

• A user can only read and write data belonging to their organization.
• Even if an application-layer bug were to occur, the database itself enforces that users cannot access data from other organizations.
• RLS policies are defined declaratively in the database schema and are enforced on every query, regardless of the application path.

3.3 Role-Based Access Control (RBAC)

Within each organization, access is controlled by roles:

Role assignments are enforced at the API level — every write operation checks the user's role and plan entitlements before proceeding.

3.4 Write-Policy Controls

On the Business plan, granular write-policy controls are available, allowing organization owners to configure which roles can perform specific write operations. This is enforced via the requireWriteActorPolicy check on all mutating API routes.

4. Application Security

4.1 API Security

• All API endpoints require authentication via secure session tokens.
• Input validation is performed using Zod schemas on every request, preventing injection attacks and malformed data.
• Rate limiting is applied to sensitive endpoints (authentication, billing, CEPA checks) to prevent abuse.
• CORS policies restrict API access to authorized origins.
• All API responses include appropriate security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy).

4.2 SQL Injection Prevention

• All database queries are parameterized through Supabase's client library, which uses prepared statements.
• No raw SQL string concatenation is used in any application code.
• Row-Level Security provides an additional layer of defense even if parameterization were bypassed.

4.3 Cross-Site Scripting (XSS) Prevention

• The application is built with React, which automatically escapes output content.
• Content Security Policy (CSP) headers are configured to restrict script execution sources.
• User-generated content is sanitized before rendering.

4.4 Cross-Site Request Forgery (CSRF) Protection

• Authentication cookies use the SameSite attribute.
• State-changing operations require authenticated API requests with session validation.

4.5 Dependency Security

• Application dependencies are regularly monitored for known vulnerabilities.
• We use lockfiles (pnpm-lock.yaml) to ensure reproducible builds with verified dependency versions.

5. Data Isolation

5.1 Multi-Tenancy Model

Tijara uses a shared-database, shared-schema multi-tenancy model with organization-level data isolation:

• Every record in the database includes an org_id field that ties it to a specific organization.
• PostgreSQL Row-Level Security policies ensure that all queries are automatically scoped to the authenticated user's organization.
• There is no mechanism within the application or database for a user to access data belonging to another organization.

5.2 Document Storage Isolation

• Uploaded documents are stored in organization-scoped paths within Supabase Storage.
• Storage access is controlled by Supabase Storage policies that mirror the RLS rules on the database.

6. Operational Security

6.1 Audit Logging

• Deal creation, status changes, cost modifications, payment recordings, and invoice generation are logged with timestamps, user identifiers, and action details.
• Authentication events (login, logout, password change) are logged.
• Audit logs are immutable and retained for the lifetime of the organization's account.

6.2 Automated Monitoring

• Application errors and exceptions are captured and monitored.
• Database performance and query latency are tracked via request timing headers.
• Cron jobs (forex sync, LC alerts, tracking polls, billing reconciliation) are monitored for successful execution.

6.3 Backup and Recovery

• Database backups: Automated daily backups are managed by Supabase with point-in-time recovery capability.
• Backup retention: Backups are retained for a minimum of 7 days (varies by Supabase plan).
• Recovery testing: We periodically verify that backups can be restored successfully.

6.4 Incident Response

In the event of a security incident:

1. Detection and containment: We will immediately investigate and take steps to contain the incident, including revoking compromised credentials and isolating affected systems.
2. Assessment: We will assess the scope and severity of the incident, including what data may have been affected.
3. Notification: If the incident involves unauthorized access to personal data, we will notify affected users and relevant authorities as required by applicable laws, including the Information Technology Act, 2000 (India) and, where applicable, the UAE PDPL, within the legally mandated timeframe.
4. Remediation: We will implement corrective measures to prevent recurrence and document the incident for internal review.
5. Communication: We will provide affected users with clear information about what happened, what data was affected, and what steps they should take.

To report a security concern, contact us at harsh@sonealabs.com with the subject line "Security Report."

7. Payment Security

Tijara does not collect, store, or process payment card details. All payment processing is handled by Lemon Squeezy, our third-party billing provider, which:

• Is PCI DSS compliant
• Processes payments through Stripe's infrastructure
• Provides secure payment pages that never transmit card data through our servers

8. Third-Party Security

We carefully evaluate the security posture of all third-party services integrated with the Platform:

9. Operational Practices

• Access to production infrastructure is restricted and monitored.
• We follow the principle of least privilege for all system access.
• Production database credentials are stored as encrypted environment variables, never in source code.
• Source code is maintained in a private repository with access controls.

10. Compliance

10.1 Regulatory Awareness

The Tijara platform is designed with consideration for:

• India Information Technology Act, 2000 and the IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011: Classification and protection of sensitive personal data, reasonable security practices.
• UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021): Respected for our users operating in the UAE — data collection consent, purpose limitation, data minimization, and data subject rights.
• DIFC Data Protection Law (No. 5 of 2020, as amended): Respected where applicable based on user jurisdiction.

10.2 VAT and Financial Data

The Platform generates invoices and financial reports. These are operational tools and do not constitute official tax documents unless configured with valid Tax Registration Numbers (TRNs). Users are responsible for ensuring their invoices and financial records comply with local tax regulations, including UAE VAT requirements and Indian GST requirements as applicable.

11. Your Security Responsibilities

While we implement extensive security controls, security is a shared responsibility. We recommend:

• Use a strong, unique password for your Tijara account
• Do not share login credentials between team members — use the invitation system to add users
• Assign the minimum necessary role to each team member (use Viewer for those who only need read access)
• Review your team member list regularly and remove users who no longer need access
• Download and review audit trails periodically for unexpected activity
• Keep your browser and operating system updated

12. Security Updates

We regularly update the Platform's dependencies, infrastructure, and security controls. Security patches for critical vulnerabilities are deployed as expeditiously as possible. We do not disclose specific vulnerability details publicly until they have been remediated.

13. Contact

For security questions, vulnerability reports, or concerns:

SoneaLabs Operated from Mumbai, Maharashtra, India Email: harsh@sonealabs.com (subject line: "Security") Website: usetijara.com

We aim to acknowledge security reports within 48 hours and provide a substantive response within 5 business days.