# 19 — Security & Compliance (CTO)

Navi handles personal data, payment data, partner data, and traveler trust. This document defines the security baseline.

## Threat model (top risks)

1. **Account takeover.** Stolen credentials → fraudulent bookings.
2. **Payment fraud.** Stolen cards → chargebacks → partner trust loss.
3. **Cross-partner data leak.** Hotel A reading Hotel B's bookings.
4. **PII exposure.** Server logs, audit logs, or backups containing tokens or full names exposed.
5. **Webhook spoofing.** Forged provider events flipping payment state.
6. **Privilege escalation.** A support agent issuing refunds beyond delegation.
7. **Mobile artifact tampering.** Reverse-engineered API calls bypassing rate limits.

Each is mitigated below.

## Authentication & session management

- Passwords stored with **Argon2id** (memory-hard).
- Email + phone verified via OTP before activation.
- JWT access tokens 15 min; refresh tokens 30 days, rotated on every use, hashed at rest.
- Device fingerprint kept on `Session` rows for anomaly detection.
- Account lockout after 8 failed attempts in 10 minutes; CAPTCHA / step-up after 4.
- Optional 2FA (SMS or TOTP) for staff; mandatory for `Admin` and `SuperAdmin`.
- Social login (Apple / Google) issues an internal user with `provider`/`providerSubject`; emails are verified by the provider.

## Authorization

- Permission-based RBAC (see `02-roles-and-permissions.md`).
- Every protected route declares `@RequirePermissions(...)`.
- Prisma scope middleware automatically filters `own` / `assigned` queries.
- A unit-test fixture verifies that a partner user cannot read another partner's data — this test is non-skippable in CI.
- Impersonation by SuperAdmin is auditable (`IMPERSONATION_START` / `IMPERSONATION_STOP`).

## Data classification

| Class | Examples | Handling |
|---|---|---|
| Public | Listing titles, destination summaries | CDN-cacheable |
| Internal | Booking aggregates, partner KPIs | Auth required |
| Confidential | User PII, addresses, phones | Authz scoped, encrypted at rest |
| Secret | Payment tokens, OTP hashes, JWT secrets | Vaulted; never logged |

Logs **must not** contain: passwords, OTP codes, full payment details (PAN/CVV), JWTs, refresh tokens. The logger has a redaction list enforced by configuration.

## Secret management

- Production secrets live in a vaulted secret manager (AWS Secrets Manager, GCP Secret Manager, or Doppler).
- Local development uses `.env` files; CI uses encrypted GitHub Actions secrets.
- `JWT_ACCESS_SECRET` and `JWT_REFRESH_SECRET` rotate quarterly with overlap.
- A secret-scan check (gitleaks or trufflehog) blocks PRs.

## Network & transport

- TLS 1.2+ everywhere; HSTS preloaded on web domains.
- API CORS allow-list explicit; no `*` for credentialed requests.
- Rate limit: 120 req/min per IP and per user, with stricter buckets on auth, OTP, and payments.
- Outbound network policies: API can only reach approved providers (egress allow-list in production).

## Web hardening

- CSP (`default-src 'self'`, scoped allow-lists for analytics and payment SDKs).
- `Strict-Transport-Security`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: strict-origin-when-cross-origin`, `Permissions-Policy` minimal.
- Cookies: `HttpOnly`, `Secure`, `SameSite=Lax` (auth) or `Strict` where possible.
- CSRF protection on cookie-based flows; state-changing operations require `Origin`/`Referer` checks or CSRF tokens.

## Mobile hardening

- Certificate pinning for the API host on production builds.
- SecureStore for tokens; no AsyncStorage tokens.
- Jailbreak/root detection on payment flows (warn, do not auto-block — accessibility implications).
- Prevent backup of sensitive prefs on iOS (`NSURLIsExcludedFromBackupKey`) and Android (no `allowBackup="true"` on debug builds).

## Payments

- Phase 3 will use a tokenized PSP (Stripe / Checkout / Telr / Network International). Card data **never** touches our servers (SAQ A scope).
- Webhooks signed; verified with HMAC and replay-protected.
- Idempotency keys required on all payment endpoints.
- Refunds only by FinanceManager+; audited end-to-end.

## Privacy & compliance

- **UAE PDPL** alignment:
  - Lawful basis declared per processing purpose.
  - Privacy notice (EN/AR) accessible from app and website.
  - Data subject rights endpoints: access, rectification, erasure, portability — implemented as `/v1/users/me` actions; SLA 30 days.
  - Data Processing Records maintained.
  - Cross-border transfer impact assessments before any non-UAE provider.
- **GDPR** equivalent rights honored where feasible (EU travelers).
- **PCI-DSS:** SAQ A scope. We never store / transmit / process card data.
- **SOC 2 readiness** target for Phase 4: control mappings, evidence collection, change management, incident response, vendor risk.
- **Children:** Navi is not directed at under-18s; signup requires confirming age ≥ 18.

## Incident response (security)

- A documented runbook (`docs/operations/22-disaster-recovery.md`) covers customer-impacting outages.
- Security incident severity tiers (S0–S3) and a 24/7 escalation path.
- Mandatory blameless postmortem within 5 business days for S0/S1.

## Vendor risk

- New providers go through a security questionnaire (data classes touched, region, cert status, breach history, sub-processors).
- Vendor risk reviews annually.
- Sub-processor list published in the privacy notice.

## Security training & dev hygiene

- Mandatory secure-coding training on hire and annually.
- PRs require at least one reviewer; security-sensitive paths need an additional senior reviewer.
- Dependency scan (Snyk / GitHub Advanced Security) blocks high/critical.
- SAST runs on every PR; DAST runs nightly against staging.