Security at MintCarb

JWT RS256 tokens. MintCarb uses asymmetric RS256 JSON Web Tokens for authentication. The private signing key never leaves our servers. Access tokens expire after 15 minutes; refresh tokens are stored in httpOnly, Secure, SameSite=Lax cookies — inaccessible to JavaScript, which prevents cookie theft via XSS.

Argon2id password hashing. All passwords are hashed using Argon2id — the winner of the 2015 Password Hashing Competition and the current OWASP-recommended algorithm. Parameters: time cost 3, memory cost 64 MB, parallelism 4. We never store plaintext passwords, and we never will.

Multi-factor authentication (TOTP). All accounts can enable time-based one-time password (TOTP) MFA using any standard authenticator app. MFA is strongly recommended for all account administrators and compliance officers.

Role-based access control. Every user has a role — Account Admin, Compliance Admin, Facility Manager, Analyst, Trader, or Viewer. Each role has clearly defined permissions. No user can access resources outside their assigned scope.

PostgreSQL row-level security (RLS). Every table in the MintCarb database has row-level security policies enforced at the database level — not only in application code. Each query automatically filters results to the requesting tenant's data. It is architecturally impossible for one company's emission data to be accessed by another company's account, regardless of application bugs.

AES-256 encryption at rest. All data volumes are encrypted at rest using AES-256. Backups are also encrypted before storage.

TLS 1.3 in transit. All communication between your browser and MintCarb servers uses TLS 1.3 — the current strongest standard. Older protocol versions (TLS 1.0, 1.1, SSL) are disabled entirely.

Dedicated infrastructure. MintCarb runs on a dedicated Hetzner server — not shared cloud instances. No other product, company, or WMAD system runs on the same server or shares the same database. Your emission data is isolated at the infrastructure level, not just the application level.

Parameterised SQL only. MintCarb uses parameterised queries exclusively — no string interpolation of user data into SQL. SQL injection is architecturally prevented, not just filtered.

Rate limiting. Authentication endpoints are rate-limited to 10 requests per minute per IP. API endpoints are limited to 100 requests per minute. Both Nginx (network layer) and SlowAPI (application layer) enforce these limits independently.

Security headers. All HTTP responses include: Content-Security-Policy, X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy (strict-origin), and Strict-Transport-Security (HSTS with 1-year max-age).

Automated security scanning. Every code push to our repository triggers automated security scans: Bandit (Python static analysis), Safety (known CVE check on all dependencies), and Semgrep (pattern-based vulnerability detection). Vulnerabilities above medium severity block deployment.

No AI training on your data. Emission records, facility data, and compliance filings are never used to train AI models — ours or anyone else's. When you use CarbonIQ, only the specific query text is sent to the AI provider (Groq). Your raw emission data is never transmitted externally.

In the event of a confirmed security incident that affects your data, MintCarb will notify affected users within 72 hours of our becoming aware of it — in line with GDPR, India DPDPA, and Singapore PDPA notification requirements.

Notifications will include: a description of what happened, what data was involved, what we have done to contain the incident, and what steps you should take.